JSR: What We Know So Far About Deno’s New JavaScript Package Registry

The JavaScript community is buzzing about JSR, a new package registry from the team behind Deno, a runtime for JavaScript, TypeScript, and WebAssembly based on the V8 JavaScript engine and Rust.

The Deno team is no stranger to introducing alternative approaches to software development. Node.js creator Ryan Dahl announced the Deno project at JSConf EU 2018 after detailing his many regrets with Node’s early design decisions. The aim of the project is to provide a faster, more secure JavaScript runtime, though the team has made Node/npm compatibility a core part of Deno.

In order to further development, Deno Land Inc. was created in 2021, with funding from Shasta Ventures and Mozilla Corporation. A year later, Deno secured an additional $21 million in a Series A funding round led by Sequoia Capital.

JSR represents Deno’s latest effort to redefine practices within the JavaScript package registry domain. It bears several significant technical divergences from npm, which has long been considered the standard package registry for the JavaScript ecosystem. JSR was unofficially announced at SeattleJS Conf 2023 and the Deno team linked to it at the bottom of their 2023 update.

A few weeks ago, the JSR website summarized what Deno is building:

• Why Choose JSR? A True TypeScript-First Environment: Efficient type checking and no transpilation hassles—write in TypeScript and deploy directly.
• Performance and Usability at the Forefront: With integrated workspaces and seamless NPM integration, JSR puts usability first.
• Secured and Accessible Modules: All modules in JSR are exposed over HTTPS, ensuring your code is always secure.
• Open Source, Community-Driven: Built by developers, for developers, JSR is shaped by the real-world needs and contributions of the JavaScript community.

Developing a New JavaScript Registry to Address npm's Limitations#

Kevin Whinnery, DevRel at Deno, explained the motivations behind creating a new package registry in his presentation on Deno 2.0:

We had a decision in front of us where we decided that we do need to go in this centralized package management direction. Is npm a thing that's going to work for us? We put in a lot of work to kind of figure out if that was going to be the case, but for a couple reasons…we ultimately found that npm had a lot of cruft in it that we didn't necessarily need in the Deno environment.

So we ultimately decided that it's going to be time for us to build a new centralized package manager that's specifically built for Deno first and some of the features of this registry are that we do want to actually take an editorial stance on content that's in the in the registry so we want to actually prevent squatting on specific names of modules and packages and prevent abandoned modules from taking up a namespace. We want to reserve the right to take that editorial stance when required. We want to ensure that packages published to the registry use semantic versioning that they're Typescript aware.

Whinnery said they want the registry to ensure that licensing is configured so packages can be used successfully. Deno is also building the registry in such a way that it can retain a lot of the efficiency they had with HTTPS Imports.

“We're pretty stoked about this direction and, again, we're not trying to copy paste node.js — we're trying to create a different type of developer experience and we think that this registry is going to be a key part of the developer experience that we're trying to create,” he said.

In March 2023, when Deno added support for package.json in order to enhance Node and npm compatibility, Dahl reiterated his team’s commitment to using HTTP imports as the backbone of the Deno module system. He also criticized the established norms of the JavaScript ecosystem, which historically leaned heavily on centralized repositories for module distribution. His vision for Deno is to leverage the web's foundational principles of decentralization in pursuit of a more flexible and secure way to manage dependencies.

“The JavaScript ecosystem’s reliance on a single centralized module registry conflicts with the web’s decentralized nature,” Dahl said. “With the introduction of ES modules, there is now a standard for loading remote modules, and that standard looks nothing like how module loading through npm works. Deno implements loading ES modules through HTTP URLs - allowing anyone to host code on any domain simply by running a file server."

First Impressions: Developers Weigh In on JSR's Potential#

A few developers have been given early access to JSR while most everyone else sits on a waiting list. Information on JSR is scant so far, but a handful of people have published their initial impressions.

“It solves a lot of the problems that deno.land/x had, but in a way the preserves all the advantages that a ‘package-management as code’ brings,” Kitson Kelly, a former engineering lead at Deno Land, said in his early review. “Add to that the ability to interoperate with the rest of the Javascript eco-system is really solving a lot of real problems.

“At the very least, having a registry that brings TypeScript on equal footing with Javascript is substantial. It is an advantage we have had in Deno land for years, but not something easily accessible to the rest of the Javascript eco-system until now.”

Kelly praised several architectural decisions made for JSR, including server support, the introduction of "zapped" code verification, which provides faster TypeScript type checking without the need for full control flow analysis, automatic generation of documentation from source code utilizing JSDoc and TypeScript annotations, and JSR's intentional limitations - allowing dependencies only from JSR, npm packages, or Node.js built-ins, for maintaining a controlled and secure package ecosystem.

Wasmer founder Syrus Akbary was also given early access to JSR and published his thoughts in a X/Twitter thread.

“It positions itself as an alternative to NPM while being independent from the runtimes, which is quite nice," Akbary said. “However, publishing new packages requires deno. The manifest itself is named deno.json and to publish you have to use deno publish.

“I know people from Deno are doing their best here, but perhaps having the publish/use untied from deno would be beneficial.”

“So far, I haven't seen any feature that gives me an order of magnitude of difference that I don't have in the alternative (npmjs.com), which makes me a bit reluctant to embrace it,” Akbary said. “JSR.io currently feels like the package manager version of Deno that allows defining dependencies via a manifest instead of code. However, why should I use it instead of npm? I get it's only compatible with ES modules... but is that a big difference?

"All in all, I do expect things to improve and I hope to see how they keep iterating on it.”

JSR may be the most attractive to TypeScript developers as its Typescript-first environment streamlines publishing packages.

"For Deno and TypeScript coders I think JSR will be the place to publish packages going forward,” web developer David Bushell said in his review. “Especially if they’re cross-runtime compatible.

“Will JSR ever usurp npm? Unlikely, but like Deno did, I hope JSR can light a fire under Node & npm and push them to modernize faster. Node still does not have first class ESM support without a flag. Is there a future where Node, like Bun, has first class TypeScript support? Will types come to the ECMAScript standard? Now I’m dreaming.

"Anyway, JSR is neat. TypeScript support and npm compatibility are the killer features. Other improvements over NPM are small but welcome.”

JSR Navigates Ecosystem Fragmentation Concerns with Commitment to npm/Node Compatibility#

Socket is keenly observing the development of JSR, aiming to support developers in their chosen ecosystems. Given JSR's novelty and niche positioning, we hope to offer integration and automatic compatibility with npm packages installed through JSR that fit into existing npm/package.json workflows, should it gain wider adoption within the community. We aim to facilitate operational continuity for developers leveraging this new registry if possible.

At the moment, Deno has kept most of its plans for JSR close to the vest, as they are likely working through feedback from early testers. Some are eager to see more competition in the JavaScript ecosystem.

“I’m excited for the innovations this new JavaScript package registry will bring,” Bloomberg JavaScript engineer Rob Palmer said.

“It's a win to have a registry that is source-aware, rather than only shipping arbitrary archives of files containing precompiled build output.”

This optimism can also be contrasted with the trademark Reddit responses:

“Please, don't. No one asked for it.”

“Deno was born dead. Stop trying to split the ecosystem. Node works great.”

The most vocal objections come from those who perceive Deno and JSR to be “marginal improvements to the Node/npm ecosystem that (if adopted) would be massive breaking changes for everyone.”

Others contend that competition is healthy, as alternative runtimes, registries, and package managers can drive the dominant players in the ecosystem towards positive change.

“Both Deno and bun are good competition,” Reddit user AtrociousCat commented. “Even if you never plan to switch from Node, the competition existing prompted Node maintainers to focus on performance a little. Bun is trying out new things and even if it dies, there might be some good ideas that will make their way to the JS ecosystem.”

In response to criticism that JSR would split the ecosystem, Reddit user NormQuestioner’s response highlights how varied opinions are on the matter:

Very bizarre take. Deno solves many of the problems Node has and allows developers to get things done in more maintainable ways, improving the DX massively.

If anything, people sticking with Node.js when they don’t need to is what’s splitting the ecosystem.

If it catches on, JSR has the potential to create a new ecosystem, but the JavaScript community will be hesitant to adopt it without seeing benefits compelling enough to warrant the switch.

“My biggest concern is community fragmentation,” web developer Kent Dodds said. “I had a similar concern when GitHub announced their package registry (before buying npm), but nobody seems to use it so that concern was never realized.

“If this gets lots of use, then I'm concerned we'll have two popular registries which will be really annoying. I'm sure they've already worked this out, but I'd like to hear how they plan to address it. npm is going nowhere.”

In response to concerns about community fragmentation on X/Twitter, Kevin Whinnery, DevRel at Deno, said, “JSR is designed to be a superset of npm rather than a replacement. JSR packages can be used in Node/Bun/* projects that use (p)npm/yarn and node_modules. You can depend on npm packages in JSR packages.”

Although the Deno team is actively working to facilitate developers in smoothly transitioning from Node to Deno, they recognize the importance of building compatibility across the ecosystem. This compatibility is crucial to their own success. Some might contend that they don’t have a shot in hell without it - allowing developers to leverage Deno’s benefits without sacrificing the vast resource network of the Node ecosystem is a necessary challenge if they want to thrive.

“Building a new version of node.js in a lower level language like Rust is not the point of Deno,” Whinnery said. “Just rewriting a better version of Node that is incrementally faster and better is not really a very interesting reason to undertake a project like this. The real goal of Deno is to try to radically simplify how software is built for the cloud.”

The new JSR registry’s distinctions are aimed at addressing the challenges and limitations developers experience with npm as it relates to security, package distribution, and dependency management. Access to JSR has not yet gone out to the waitlist, but when it does, a broader set of early reviews will offer a better picture of how much effort the Deno team will need to invest in persuading the community to adopt it, which will ultimately determine its viability as a competitive alternative in the ecosystem.