JSR Now in Public Beta, Aims to Shift Community Towards Using ESM Modules

Deno opened access to JSR today, its new JavaScript registry. They announced the public beta at the 2024 JSWorld Conference, which hosted 2,500 JavaScript enthusiasts.

Introducing a new package registry alongside the established npm registry is no small endeavor, but JSR has so far received a positive reception. The registry was designed for TypeScript and ESM. It makes publishing TypeScript code infinitely more simple, as JSR will automatically generate API docs, .d.ts files, and transpile the code for cross-runtime compatibility. The packages are then available as web-standard ECMAScript modules.

Even though it’s optimized for TypeScript, JSR works with both Deno and npm-based projects, including Node, Bun, Cloudflare workers, and more. Now that the website is public, it’s clear that JSR’s creators intend to make it as compatible with the rest of the ecosystem as possible, stating that JSR builds on npm and exists as a superset:

JSR isn't a replacement for the npm registry; it's a superset of npm.

JSR modules can be used with any JavaScript package manager, and in any project with a node_modules folder.

One of the main differences from npm is the publishing experience, which is more straightforward for TypeScript developers. JSR packages are published as ESM modules and you cannot publish CommonJS modules.

JSR has also implemented strict anti-spam/squatting policies, and scopes are limited per user account (but can have multiple members).

Although package versions cannot be deleted, versions can be “yanked” in the case of a critical bug or other concern. This has the following effects, according to JSR’s documentation:

• Semver resolution ignores the version when resolving dependencies.
• It shows a warning on the package page that the version has been yanked.
• It prevents the version from being shown in search results.
• It marks the version as yanked in the package’s version list.
• Yanked versions are not considered when determining the latest version of a package.

JSR packages are also scored based on various factors, such as documentation, best practices (packages should not use slow types, which is detected through static analysis), discoverability, and compatibility. The score determines how packages show up in search results.

The new registry uses secure, token-less publishing for better protection against supply chain attacks.

JSR is open source, licensed under the MIT license and all the code is available on GitHub, including the frontend, CLI, API server, monitoring tools, and more. It runs on Google cloud, with a Rust backend and Fresh frontend, using a PostgreSQL database.

JSR: A Push to Shift the Community Towards Using ESM Modules#

When introducing JSR at JSWorld today, the Deno team noted that npm and Node are both “really showing their age,” which is one of the motivations that drove them to create the new registry. npm hasn’t evolved much in the past ten years and some perceive that it's no longer an easy place to publish modules.

JSR docs cite the following reasons the Deno team created the registry:

• ECMAScript modules have arrived as a standard. The web platform has now adopted ESM as the module format of choice, superseding CommonJS.
• There are more JavaScript runtimes than just Node and browsers. With the emergence of Deno, Bun, workerd, and other new JavaScript environments, a Node-centric package registry no longer makes sense for the entire JS ecosystem.
• TypeScript has emerged as a de facto standard. TypeScript, as a superset of JavaScript and test bed for the latest ECMAScript features, has emerged as a default choice for non-trivial JavaScript codebases. A modern registry should be designed with TypeScript in mind.

Deno engineer Luca Casonato was recently on the Syntax podcast and this clip encapsulates why the team decided to carve a new path forward with JSR:

The full episode is available on YouTube.

“ESM is much better to statically analyze than CommonJS,” Casonato said. “We do a lot of static analysis on the source code we upload because we provide things like documentation generation and certain links and things that are built into the registry and we wouldn’t be able to do those if we had to support CommonJS in addition to ESM.

“And also it makes it very simple - you don’t have to make a choice when you’re writing a package. You’re writing ESM.”

JSR aims to push this standard forward and has a strong shot at success, with the native support for TypeScript.

Now that JSR is in public beta, developers are exploring the new registry and experimenting with publishing and using packages.

JSR addresses the confusion and disorder surrounding TypeScript, ESM, and CommonJS on npm, which have made it increasingly challenging for developers to manage dependencies, interoperability, and module formats effectively, leading to complications in development workflows and project architecture.

It also seems to be a response to the growing sentiment within the developer community that npm is not being maintained with the attention and responsiveness required to meet the evolving needs of the JavaScript ecosystem.

JSR is currently funded by the Deno, “designed to be a public good for the JavaScript community,” according to the docs, and is designed to be cheap to run. The company promises that it will always be free to use. Long term they may seek to fund the registry through sponsorships, donations, or by establishing a foundation.