Deno isn't just for TypeScript, anymore! Did you know that you can also use Deno to import and run JavaScript packages from npm?
As long as your package is written as ESM (JavaScript's native module syntax) and doesn't rely on any Node-specific behavior/imports, Deno can load and run JavaScript from any URL without breaking a sweat. Pika already hosts a search catalog of 80,000+ ESM packages on npm with more being added every day.
All of this makes the Pika CDN -- our modern CDN for the npm ecosystem -- a great fit for Deno. With the Pika CDN, you can import any npm package from a single, hosted URL. This has always been a good fit for websites, but now it is an even better fit for Deno. That's because Deno has no package manager, so importing packages from URLs is already built in to the Deno workflow.
Introducing "X-TypeScript-Types"
But what about type declarations? Deno is a TypeScript runtime, after all. It would be a shame if you couldn't also fetch the type declarations that exist inside of each npm package (or via the community-generated @types/ project by DefinitelyTyped) whenever you import a JS npm package.
Well, now you can!
In collaboration with the Deno team for their recent v0.32.0 release, Pika CDN now hosts type declarations for every package that provides them! Import an npm package from our CDN and Deno will automatically fetch its type declarations along with it.
With this new feature, your programs get an extra level of stability with automatic warnings from Deno when a package is used incorrectly.
This is all thanks to Deno's new "X-TypeScript-Types" response header support. Here's how it works:
-
Hosting the type declarations: For Deno to read package type declarations, they have to exist somewhere on our CDN. We do the work at build-time to find the type files for your package and then host them at the
/types/*package URL subpath. -
Telling Deno where to find them: Each package on the CDN that has valid types responds with a
X-TypeScript-Typesheader. When Deno sees this header from an import, it automatically fetches the types and connects them to the import.
If no type declarations exist on npm, we don't send the header. In that case, Deno will read the JS files and make its best guess at what its interface looks like. We could try to do the same on the CDN, but for now we feel pretty confident that Deno is better at this than we are :)
Exciting Times!
None of this would have been possible without the efforts of @kitsonk and the entire team of Deno contributors.
With these changes, Pika CDN is now THE BEST PLACE to get npm packages that run on Deno. This is something that we're extremely proud of, and a goal that we'll keep improving on as Deno works towards their v1.0 release. Exciting times, indeed!
We can't wait to see what you build with Deno and our CDN. Reach out to us on Twitter with any questions, comments, and links to what you've built.
✌️
- @fks
Top comments (4)
Awesome work for deno 👍
Would you be so kind to have a look at github.com/gcanti/fp-ts/issues/113...? Pika CDN seems to patch import statements for deno correctly. But it seems
declare module '...'statements are not patched. This might be the reason some modules won't load for deno. fp-ts for example. Thank you :)Hey Thomas, thanks for the ping! That feature has been added, and the package now loads successfully! I left a follow up comment in the issue.
Hope that helps!
Not sure where to raise this as it's not an fp-ts issue but I've been trying to work with this module via pika in deno again since the v1 release but having some issues.
I think the issue lies in the way that the fp-ts library wants you to import things versus Pika which doesn't like you importing things from subfolders in the module.
I've posted a discussion on Pika with some more details about this - would love to hear your thoughts on it if you can spare a moment pika.dev/npm/fp-ts/discuss/1
Thanks, Luke!