Broken build for @types/d3

[erikbrinkman]

d3 typescript types seem to be broken. Going off the "build" I pulled just now the "warning" message is

[Package Error] "@types/d3@v6.3.0" could not be built.
Installing package...
No ESM dependencies found!
  At least one dependency must have an ESM "module" entrypoint. You can find modern, web-ready packages at https://www.skypack.dev
No ESM dependencies found!
  At least one dependency must have an ESM "module" entrypoint. You can find modern, web-ready packages at https://www.skypack.dev

I'm not exactly sure why this is, some of the other independent d3 libraries also have broken types. The definition of that declaration file just re-exports the others.

[drwpow]

Yes Skypack currently doesn’t serve types-only packages, as currently TypeScript has trouble loading them. If you‘re using Deno, we recommend adding ?dts to the end of a normal module import, like so: cdn.skypack.dev/d3?dts.

How are you using the types package for D3? Just out of curiosity

[erikbrinkman]

I think I tried that, and it failed, so I was trying to hack around it by just importing the types. Trying to export d3 that why I get:

error: Error: Unable to resolve media type for specifier: "https://cdn.skypack.dev/-/d3@v6.5.0-bb5DbjO9VTkAQf6Ujv1h/dist=es2020,mode=types/null"

where I'm just doing

export * as d3 from "https://cdn.skypack.dev/d3?dts";

In this particular instance I have functions that a scale, in this case particularly a d3.ScaleContinuousNumeric<number, number> so the types were necessary to type that appropriately.

[drwpow]

Ah I see. Yes you’re right—there seems to be a bug in packages that rely on external types from DefinitelyTyped, which d3 does. I’ve located the fix, and it should be in production soon! Sorry for the inconvenience.

[jasonwilliams]

Yes Skypack currently doesn’t serve types-only packages, as currently TypeScript has trouble loading them. If you‘re using Deno, we recommend adding ?dts to the end of a normal module import, like so: cdn.skypack.dev/d3?dts.

How are you using the types package for D3? Just out of curiosity

Hey @drwpow do you know if there's a way to download the declarations from skypack (to get round the remote declarations problem)? https://github.com/lostintangent/codeswing/issues/25 is a project like codepen which allows you to choose libraries and immediately code, it uses Skypack under the hood but doesn't have a way of getting intellisense. I was wondering if there's a way of pointing to https://cdn.skypack.dev/-/jquery@v3.5.1-GJsJJ2VEWnBDZuot9fRf/dist=es2020,mode=types/index.d.ts for example and downloading all of the reference paths it refers to into a folder. I'm sure Deno achives something similar?

I guess this would need some sort of crawler and I don't know if that exists

[drwpow]

I was wondering if there's a way of pointing to https://cdn.skypack.dev/-/jquery@v3.5.1-GJsJJ2VEWnBDZuot9fRf/dist=es2020,mode=types/index.d.ts for example and downloading all of the reference paths it refers to into a folder.

Sort of. If you request ?dts at the end of a URL you’ll get an x-typescript-types header that points to that declaration file to download. You can use that somewhat programatically, by getting a types download for every package. But you’d need to do that for all a package’s dependencies and sub-dependencies, too.

[jasonwilliams]

I was wondering if there's a way of pointing to https://cdn.skypack.dev/-/jquery@v3.5.1-GJsJJ2VEWnBDZuot9fRf/dist=es2020,mode=types/index.d.ts for example and downloading all of the reference paths it refers to into a folder.

Sort of. If you request ?dts at the end of a URL you’ll get an x-typescript-types header that points to that declaration file to download. You can use that somewhat programatically, by getting a types download for every package. But you’d need to do that for all a package’s dependencies and sub-dependencies, too.

Yep, the issue I noticed is some declaration files have relative paths to others. So it doesn’t seem as simple as just downloading the file the header points to. It looks like there would need to be some crawler that also fetches sub dependencies, and from what I can tell no such crawler exists (apart from the one built into Deno)

[drwpow]

Correct—Deno does the crawling. For the JS modules themselves this works very well if you think about it—everything is all browser-powered and the browser just tells us what it needs. But as you’ve pointed out this is the opposite of what TypeScript needs, and it’s hard to know from the CDN end every single type that’s needed for your app.

We’re really hoping with all the recent browser additions TS starts supporting URLs soon 🤞 but I’ve caught no wind of the TS team putting that on the roadmap.

[jasonwilliams]

and it’s hard to know from the CDN end every single type that’s needed for your app.

I’m not sure I follow this bit. If I request jQuery (with ?dts) I just want the type declaration for jQuery and nothing else (preferably in a single file or an easy way of getting everything). As a CDN you don’t need to care about what the rest of my app needs, that’s down to me to request the other bits.

We’re really hoping with all the recent browser additions TS starts supporting URLs soon 🤞 but I’ve caught no wind of the TS team putting that on the roadmap.

yeah I find it unlikely to happen anytime soon, which is why I was wondering if there’s any possibility of some interim. Something that can crawl and get declarations and download them to a local adjacent file.

[drwpow]

If I request jQuery (with ?dts) I just want the type declaration for jQuery and nothing else

Sorry; probably worth explaining that many type definitions actually need dependencies. Many type definitions aren’t self-contained like this. For example, @types/react needs @types/prop-types, @types/scheduler, and csstype. Deno, being URL-based, just requests (“crawls”) those as it’s loading the file, which point to other type defs on Skypack.

So if you were trying to download the types only for react, you’d find you need to crawl at least 4 packages to get everything (this is all done for you in an npm install). So the problem is trickier than it seems at first glance: many packages’ types are spread across multiple packages.