JSR: The JavaScript Registry

Original Article ↗ Hacker News Discussion ↗

A new JavaScript package registry called JSR, created by the Deno team, aims to provide a TypeScript‑first, ESM‑only alternative to npm while remaining interoperable with existing npm packages and tooling. Supporters highlight built-in type handling, automatic docs, provenance, and tighter integration with modern runtimes as key advantages over the aging, Microsoft‑controlled npm registry. Critics question the need for another central registry, worry about ecosystem fragmentation, naming and governance issues, and express concern over design choices such as penalizing heavy type inference and relying heavily on TypeScript in the absence of a formal standard.

Purpose and Design of JSR

  • New centralized registry for JavaScript/TypeScript, built by the Deno team but meant to be runtime-agnostic.
  • Motivated by problems with URL-based imports in Deno: duplicated dependencies (no semver-based deduping) and fragile URLs that can disappear.
  • Focuses on TypeScript and ESM: you publish TS source and JSR handles transpilation, .d.ts generation, docs, and cross-runtime builds.
  • HTTPS imports in Deno remain supported, but JSR is positioned as the more robust default.

TypeScript, Syntax-Only Approach, and “Slow Types”

  • Registry relies on TypeScript syntax, not the full type system; no TSC-based analysis.
  • To keep type operations fast and stable, it strongly encourages explicit public API types and limits inference (“slow types” get a lower score, but can still publish).
  • Upcoming TS options like isolatedDeclarations and editor quick-fixes are cited as easing the friction.

Relationship to npm and Tooling

  • JSR is a registry, not a package manager; integrates with existing tools via npm-style APIs and node_modules.
  • JSR modules can depend on npm modules and vice versa; there’s an npm compatibility layer that emits JS + .d.ts for Node.
  • Some confusion over marketing language like “superset of npm”; several commenters suggest clearer terms like “additive” or “complementary.”
  • Existing Deno-to-npm workflows (e.g., dnt) remain viable short term; longer term, JSR aims to cover that use case directly.

Governance, Namespaces, and Immutability

  • Scopes are curated; obvious brand scopes can be reassigned to verified owners.
  • Past versions remain immutable and available; new scope owner can publish newer versions under the same scope.
  • Some see this as repeating past registry naming dramas; others propose DNS- or URN-based naming to avoid collisions.

Runtime, Browser, and WASM Use

  • Works with Deno, Node, Bun; Node uses a compatibility layer.
  • Browser usage is not first-class yet; external services like esm.sh are mentioned for HTTP/ESM imports of JSR packages.
  • Planned support for WASM source imports via the source-phase imports proposal.

Reception and Critiques

  • Enthusiasm: better TS support, auto-docs, provenance, alternative to a Microsoft-controlled npm, open source implementation.
  • Skepticism: adds another registry and perceived fragmentation; some see features as solvable with better npm-side tooling.
  • Concerns about over-reliance on TS, extra build “magic,” semver behavior, and marketing (name “JSR,” TS focus vs “JavaScript” branding, AI-like landing pages).