The is a public registry for code, hopefully code written specifically for Deno. It is a public registry though and all it does is “redirect” Deno to the location where the code exists. It doesn’t transform the code in any way. There is a lot of great code on the registry, but at the same time, there is some code that just isn’t well maintained (or doesn’t work at all). If you are familiar with the npm registry, you know that as well, there are varying degrees of quality.

    Because it simply serves up the original published source code, it doesn’t really help when trying to use code that didn’t specifically consider Deno when authored.

    Deno friendly content delivery networks (CDNs) not only host packages from npm, they provide them in a way that maximizes their integration to Deno. They directly address some of the challenges in consuming code written for Node:

    • They resolve all the dependencies as the modules are served, meaning that all the Node specific module resolution logic is handled by the CDN.
    • Often, they inform Deno of type definitions for a package, meaning that Deno can use them to type check your code and provide a better development experience.
    • The CDNs also “polyfill” the built-in Node modules, making a lot of code that leverages the built-in Node modules just work.
    • The CDNs deal with all the semver matching for packages that a package manager like npm would be required for a Node application, meaning you as a developer can express your 3rd party dependency versioning as part of the URL you use to import the package.

    esm.sh

    is a CDN that was specifically designed for Deno, though addressing the concerns for Deno also makes it a general purpose CDN for accessing npm packages as ES Module bundles. esm.sh uses esbuild to take an arbitrary npm package and ensure that it is consumable as an ES Module. In many cases you can just import the npm package into your Deno application:

    esm.sh supports the use of both specific versions of packages, as well as versions of packages, so you can express your dependency in a similar way you would in a package.json file when you import it. For example, to get a specific version of a package:

    1. import React from "https://esm.sh/react@17.0.2";

    Or to get the latest patch release of a minor release:

    esm.sh also automatically sets a header which Deno recognizes that allows Deno to be able to retrieve type definitions for the package/module. See Using X-TypeScript-Types header in this manual for more details on how this works.

    The CDN is also a good choice for people who develop in mainland China, as the hosting of the CDN is specifically designed to work with “the great firewall of China”, as well as esm.sh provides information on self hosting the CDN as well.

    Check out the for more detailed information on how the CDN can be used and what features it has.

    Skypack

    is designed to make development overall easier by not requiring packages to be installed locally, even for Node development, and to make it easy to create web and Deno applications that leverage code from the npm registry.

    Skypack has a great way of discovering packages in the npm registry, by providing a lot of contextual information about the package, as well as a “scoring” system to try to help determine if the package follows best-practices.

    Skypack detects Deno’s user agent when requests for modules are received and ensures the code served up is tailored to meet the needs of Deno. The easiest way to load a package is to use the lookup URL for the package:

    1. import React from "https://cdn.skypack.dev/react";
    3. export default class A extends React.Component {
    4.     return <div></div>;
    6. }

    By default, Skypack does not set the types header on packages. In order to have the types header set, which is automatically recognized by Deno, you have to append ?dts to the URL for that package:

    1. import { pathToRegexp } from "https://cdn.skypack.dev/path-to-regexp?dts";
    3. const re = pathToRegexp("/path/:id");

    See in this manual for more details on how this works.

    Skypack docs have a specific page on usage with Deno for more information.

    There are a couple of other CDNs worth mentioning.

    UNPKG

    UNPKG is the most well known CDN for npm packages. For packages that include an ES Module distribution for things like the browsers, many of them can be used directly off of UNPKG. That being said, everything available on UNPKG is available on more Deno friendly CDNs.

    JSPM

    The jspm.io CDN is specifically designed to provide npm and other registry packages as ES Modules in a way that works well with import maps. While it doesn’t currently cater to Deno, the fact that Deno can utilize import maps, allows you to use the to generate an import-map of all the packages you want to use and have them served up from the CDN.

    • Deno does not (and will not) support Node plugins. If the package requires a native plugin, it won’t work under Deno.
    • Dependency management can always be a bit of a challenge and a CDN can make it a bit more obfuscated what dependencies are there. You can always use with the module or URL to get a full breakdown of how Deno resolves all the code.