JSR Working Group Kicks Off with Ambitious Roadmap and Plans for Open Governance

At the end of October, JSR, the open source package registry for modern JavaScript and TypeScript, convened its first working group meeting. Although Deno currently pays to keep JSR running, the registry is not a Deno project. Its creators intend for JSR to be an open source community-run project, and they are working towards adopting an open governance model.

During the first JSR Working Group meeting, participants discussed the current state of JSR in the JavaScript ecosystem, the roadmap, and recruiting for governance.

They opened by giving a brief introduction to JSR with a slide deck that clearly articulates what JSR is and what it isn’t, and where its modules currently operate:

• Designed for TypeScript
• JSR packages are distributed as web-standard ECMAScript modules
• JSR isn't a replacement for the npm registry; it's a superset of npm
• JSR modules can be used in Node.js, Deno, Bun, Cloudflare Workers, and more

JSR and Deno engineer Luca Casonato highlighted the mission for the project - to “level up the JavaScript ecosystem” and ensure that package management is ready for the next 10 years of JavaScript development.

What’s on the JSR Roadmap#

In their inaugural working group meeting, the JSR team outlined a clear and strategic roadmap centered around two primary focus areas: enhancing the publishing process for developers entrenched in the Node ecosystem and elevating the overall consumer experience for package users.

JSR currently enables the publishing of new TypeScript packages but lacks guidance for type checking, does not consistently handle existing .js and .d.ts file pairs. Local testing of npm-emitted code is still challenging, and JSR does not support publishing JSX.

Streamlining Publishing for the Node Ecosystem:

Recognizing the vast number of developers who rely on Node.js, the JSR roadmap aims to simplify the transition and integration of existing Node packages into the JSR registry through these key initiatives:

• Automatically pick up .d.ts + .js pairs
• Provide tool to generate JSR config from package.json
• Including flagging tsconfig.json options that should be changed (like isolatedModules)
• Provide tooling to perform npm tarball generation locally, mainly for testing

Improving Consumer Experience:

On the consumer side, JSR is committed to making package usage more seamless and intuitive, through a few key improvements:

• Easier use of JSR packages by remapping @jsr scope on npm by default in package managers
  • No more need for .npmrc
  • This makes it easier for existing npm packages to rely on JSR packages
• Expose license and attestation more prominently on the website, including through search⠀
• First class support for changelogs, including auto-generated API changelogs

Moving Towards Open Governance and Long-Term Sustainability#

JSR’s collection of community packages has grown to more than 7,400 packages in the nine months since it went into public beta. Developers rave about how much time is saved by using JSR to publish Typescript packages, and the registry is solidifying its position as a vital resource in the JavaScript ecosystem.

JSR is currently hosted on Google Cloud with a Rust backend, Postgres database, and Deno/Fresh on the frontend. Current costs are $400 a month for database and compute and JSR’s engineers don’t expect this to grow much. The Deno company is willing to pay for hosting infrastructure, even after moving to a foundation.

The main concerns for long-term sustainability are the variable cost of bandwidth, which is increasing as registry usage grows. The group is hoping to find some CDN partners that can help lessen the bandwidth costs.

As the registry grows, the group has discussed moving JSR into an open foundation by establishing a JSR governance board to oversee the transition. The group noted that JSR is already operationally detached from Deno, along with the JSR brand, so it should not be complicated to move it into an open foundation where it won’t be controlled by a single entity.

The working group is currently seeking trusted individuals with track records to oversee this process and decide the overall direction of the registry. They are also looking for engineering help on JSR, which is written in Rust and TypeScript. It’s open source and there are some issues already labeled as good-first-issue in the JSR repository.

JSR Moderation Group

A JSR moderation group is another missing piece of the puzzle that will be put in place following the formation of the JSR governance board. This group will handle the day-to-day administration of the public registry. This includes operations like enforcing naming and content policies, responding to user requests and issues, and increasing limits. The group will meet on a regular basis to discuss and evolve the policies and make critical decisions.

Check out the meeting recording and the slides for more details on applying to contribute to JSR’s governance, moderation, and engineering efforts. The working group plans to hold a bi-weekly recurring open meeting where they will answer questions, respond to feedback, and collectively plan and discuss the future roadmap of JSR. The next meeting is happening this week on Friday, November 8, at 7PM EST.