NPM, the Node Package Manager, hosts millions of packages and serves billions of downloads annually. It has served well over the years but has its shortcomings, including with TypeScript build complexity and package provenance. Recently, NPM’s provenance issues have resulted in prominent security breaches, leading more developers to seek alternatives.

The JavaScript Registry (JSR), brought to us by Deno creator Ryan Dahl, was designed to overcome these issues. With enterprise adoption already underway, it is time to see what the next generation of JavaScript packaging looks like.

The intelligent JavaScript registry

Whether or not you opt to use it right away, there are two good reasons to know about JSR. First, it addresses technical issues in NPM, which are worth exploring in detail. And second, it’s already gathering steam, and may reach critical mass toward ubiquity in the near future.

JSR takes a novel approach to resolving known issues in NPM. For one thing, it can ship you compiled (or stripped) JavaScript, even if the original package is TypeScript. Or, if you are using a platform that runs TypeScript directly (like Deno), you’ll get the TypeScript. It also makes stronger guarantees and offers security controls you won’t find in NPM. Things like package authentication and metadata tracking are more rigorous. JSR also handles the automatic generation of package documentation.

Every package consumer will appreciate these features, but they are even more appealing to package creators. Package authors don’t need to run a build step for TypeScript, and the process of publishing libraries is simpler and easier to reproduce. That’s probably why major shops like OpenAI and Supabase are already using JSR.

JSR responds to package requests based on your application setup and requires little additional overhead. It is also largely (and seamlessly) integrated with NPM. That makes trying it out relatively easy. JSR feels more like an NPM upgrade than a replacement.

How JSR works

How to handle TypeScript code in a JavaScript stack has become a hot topic lately. Mixing TypeScript and JavaScript is popular in development, but leads to friction during the build step, where it necessitates compiling the TypeScript code beforehand. Making type stripping a permanent feature in TypeScript could eventually solve that issue, but JSR resolves it today, by offloading compilation to the registry.

JSR is essentially designed as a superset of the NPM registry, but one that knows the difference between TypeScript and JavaScript.

When a package author publishes to JSR, they upload the TypeScript source directly, with no build step required. JSR then acts as the intelligent middle layer. If you request a package from a Deno environment, JSR serves the package in the original TypeScript version. But if you request it from a Node environment (via npm install), JSR automatically transpiles the code to ESM (ECMAScript Modules)-compliant JavaScript and generates the necessary type definition (.d.ts) files on the fly.

This capability eliminates the so-called TypeScript tax that has plagued library authors for years. There’s no need to configure complex build pipelines or maintain separate distribution folders. You simply publish code, and the registry adapts it to the consumer’s runtime.

It’s also important to know that JSR has adopted the modern ESM format as its module system. That isn’t a factor unless you are relying on an older package based in CommonJS (CJS). Using CJS with JSR is possible but requires extra work. Adopting ESM is a forward-looking move by the JSR team, supporting the transition of the JavaScript ecosystem to one approved standard: ESM.

The ‘slow types’ tradeoff

To make its real-time transpilation possible, JSR introduces a constraint known as “no slow types.” JSR forbids global type inference for exported functions and classes. You must explicitly type your exports (e.g., by defining a function’s return type rather than letting the compiler guess it). This is pretty much a common best practice, anyway.

Explicitly defining return types allows JSR to generate documentation and type definitions instantly without running a full, slow compiler pass for every install. It’s a small tradeoff in developer experience for a massive performance gain in the ecosystem.

Security defaults

Perhaps most handy for enterprise users, JSR tackles supply-chain security directly, through provenance. It integrates with GitHub Actions via OpenID Connect.

When a package is published, JSR generates a transparency log (using Sigstore). The log cryptographically links the package in the registry to the specific commit and CI (continuous integration) run that created it. Unlike the “blind trust” model of the legacy NPM registry, JSR lets you verify that the code you are installing came from the source repository it claims.

This also makes it easier for package creators to provide the security they want without a lot of extra wrangling. What NPM has recently tried to backfill via trusted publishing, JSR has built in from the ground up.

Hands-on with the JavaScript Registry

The best part of JSR is that it doesn’t require you to abandon your current tooling. You don’t need to install a new CLI or switch to Deno to use it. It works with npm, yarn, and pnpm right out of the box via a clever compatibility layer.

There are three steps to adding a JSR package to a standard Node project.

1. Ask JSR to add the package

Instead of the install command, you use the JSR tool to add the package. For example, to add a standard library date helper, you would enter:

npx jsr add @std/datetime

Here, we use the NPX command to do a onetime run of the jsr tool with the add command. This adds the datetime library to the NPM project in the working directory.

2. Let JSR configure the package

Behind the scenes, the npx jsr add command creates an .npmrc file in your project root that maps the @jsr scope to the JSR registry (we will use this alias in a moment):

@jsr:registry=https://npm.jsr.io

You don’t have to worry about this mapping yourself; it just tells NPM, “When you see a @jsr package, talk to JSR, not the public NPM registry.”

3. Let JSR add the dependency

Next, JSR adds the package to your package.json using an alias. The dependency will look something like this:

"dependencies": {
  "@std/datetime": "npm:@jsr/std__datetime@^0.224.0"
}

Again, you as developer won’t typically need to look at this. JSR lets you treat the dependency as a normal one, while NPM and JSR do the work of retrieving it. In your program’s JavaScript files, the dependency looks like any other import:

import { format } from "@std/datetime";

JSR and the evolution of JavaScript

JSR comes from the same mind that gave us Node.js: Ryan Dahl. In his well-known 2018 talk, 10 things I regret about Node.js, Dahl discussed ways the ecosystem had drifted from web standards and spoke on the complexity of node_modules. He also addressed how opaque the Node build process could be.

Dahl initially attempted to correct these issues by creating Deno, a secure runtime that uses standard URLs for imports. But JSR is a more pragmatic pivot. While it is possible to change the runtime you use, the NPM ecosystem of 2.5 million packages is too valuable to abandon.

JSR is effectively a second chance to get the architecture right. It applies Deno’s core philosophies (security by default and first-class TypeScript) to the broader JavaScript world. Importantly, to ensure it serves the whole ecosystem (not only Deno users), the project has moved to an independent open governance board, ensuring it remains a neutral utility for all runtimes.

The future of JSR and NPM

Is JSR on track to be an “NPM killer”? Not yet; maybe never. Instead, it acts as a forcing function for the evolving JavaScript ecosystem. It solves the specific, painful problems of TypeScript publishing and supply-chain security that NPM was never designed to handle.

For architects and engineering leads, JSR represents a safe bet for new internal tooling and libraries, especially those written in TypeScript. JSR’s interoperability with NPM ensures the risk of lock-in is near zero. If JSR disappears tomorrow, you’ll still have the source code.

But the real value of JSR is simpler: It lets developers write code, not build scripts. In a world where configuration often eats more time than logic, that alone makes JSR worth exploring.