After a decade of loving and fighting Javascript build systems, I’ve found myself using Deno—Ryan Dahl’s “next-generation Javascript runtime”—more and more when I just want to get after it and write some Typescript. Recently I wrote a utility that was easy to imagine using in multiple projects. I checked JSR, “the open-source package registry for modern JavaScript and TypeScript” first introduced by the Deno team, and no similar utility existed. I wondered if publishing was as easy as they claimed. Let me tell you, it was. You can use JSR to publish Typescript to just about any setting with almost no configuration for the maintainer.
Publishing to NPM
Publishing cross-compatible Javascript to NPM is a headache. As Dr. Axel Rauschmayer recently documented, there is a lot to keep in mind, a package maintainer must understand:
- how to simultaneously support Javascript and Typescript, publishing type declarations alongside your Javascript
- module resolution, publishing exports to support both CommonJS and ESM Modules
- as an additional wrinkle, you need awareness of how your package will be distributed via NPM and CDNs (e.g. esm.sh, unpkg)
JSR handles all of this, by applying Deno’s typescript-first and ESM-first approaches to package publishing. Admittedly, JSR’s approach to handling CommonJS is that it simply doesn’t, if that is a hard requirement for your package then JSR is probably not the solution for you. It’s approach to supporting Javascript and NPM is fantastic. You can write Typescript and JSR will handle the correct compilation for you with JSR’s NPM compatibility layer. This makes it straightforward to include a JSR package in your Node project or via a browser bundling tool (e.g. Vite). JSR is not a CDN and does not support referencing packages from the browser in a production environment. No worries though, JSR is supported by esm.sh.
Documentation
Beyond the ease of publishing and consuming JSR packages, the experience is thoughtful all around.
The JSR Score encourages you towards best practices, including sharing compatibility information. Referencing the browser and server APIs you used should give you a good idea of where your package can be used. For example, since my package only uses the Crypto.getRandomValues() I can be confident that my package can be used across Javscript runtimes and modern browsers.
A delightful surprise I did not anticipate, is that my JSDoc comments would be rendered directly on the JSR Registery as helpful documentation. The Javascript community often invests in lovely documentation, but it can mean having to spend time orienting yourself in order to find simple answers. Other languages (e.g. Python, GO) often have common documentation tools that increase familiarity across packages, making it quick to find a simple answer about how a particular API is intended to function. JSR provides a turn-key solution making documentation simple and consistent. Mercifully, the JSR team also has a reasonable opinion about line length.
Incredible tools have enabled us to write higher quality Javascript years ahead of certain APIs and standards being widely available. As those standards have become dependable I’m eager to shed the weight of maintaining configuration for those tools. I’m really excited about a “buildless” future that maintains the advancements that have been made. I understand it will be a while until codebases can abandon NPM, but I hope that more and more package maintainers adopt a JSR-first approach.