The Deno team recently beta released JSR, a new JavaScript registry that strives to better fit the current needs of modern development and unify a fragmented JavaScript ecosystem. In particular, JSR embraces ESM (JavaScript native modules), natively accepts TypeScript packages, and supports major JavaScript runtimes (e.g., Node, Deno, Bun, browsers, miscellaneous serverless environments).
The npm package manager, originally released in 2010, was originally designed around Node.js, the CommonJS module system, and vanilla JavaScript. Fast forward 15 years, JavaScript now has a native module system (ESM), TypeScript has become the main choice for typed JavaScript, and a test bed for new JavaScript language features. Importantly, JavaScript is no longer limited to the browser and Node.js. Cloud providers often run their own optimized JavaScript runtime. Deno and Bun are also growing as alternatives to Node.js, revisiting key assumptions and focusing on developer experience.
JSR, the newly released JavaScript registry is free and open-source, supersedes CommonJS modules with ESM, natively accepts TypeScript packages, and as a goal seeks to improve on the developer experience, performance, reliability, and security of npm.
JSR’s documentation also describes cross-runtime packages as a design goal:
The goal of JSR is to work everywhere JavaScript works, and to provide a runtime-agnostic registry for JavaScript and TypeScript code. Today, JSR works with Deno and other npm environments that populate a
node_modules. This means that Node.js, Bun, Cloudflare Workers, and other projects that manage dependencies with apackage.jsoncan interoperate with JSR as well.
JSR strives nonetheless to reuse the npm ecosystem by allowing JSR packages to depend on npm packages:
JSR is designed to interoperate with npm-based projects and packages. You can use JSR packages in any runtime environment that uses a
node_modulesfolder. JSR modules can import dependencies from npm.
JSR also uses a package scoring system to nudge package publishers toward best practices in code distribution. For instance, a ranking score rewards packages that include comprehensive JSDoc documentation on each exported symbol (used to automatically generate package documentation). The ranking score includes other factors such as the presence of optimal type declarations for fast type-checking and the compatibility with multiple runtimes.
Developers are encouraged to review the release note for miscellaneous examples of publishing flows. For instance, a package creator publishing a TypeScript package with JSR and Deno needs to populate at least three files: a jsr.json metadata file, the TypeScript source files for the package, and a README.md file providing an overview of the package. The jsr.json file would go as follows:
{
"name": "@kwhinnery/yassify",
"version": "1.0.0",
"exports": "./mod.ts"
}
The exports field specifies the package modules that are exposed to the package consumers.
The package would then be published in a Deno environment with deno publish and in a Node.js environment with npx jsr publish.
The Deno standard library was recently made available on JSR. Developers can review the package documentation guidelines provided online in order to optimize their package ranking score. The Deno team additionally published an in-depth blog post on how they built JSR.