How to properly publish a JSR package with browser compatibility?
I've been getting back to Deno and JS/TS development in general these last few days and I've been scratching my head over publication of a library I'm working on, I had in mind to publish it in a way it's easily available in Deno and in browsers, then I've stumbled upon JSR, but it marking packages as "browser compatible" is really confusing to me, especially when I can't seem to see any JS files in the published packages that are marked as browser compatible, is JSR not actually intended to be used directly in browser JS? Is there another CDN that I'm supposed to use to import JSR packages in browsers?
So far my hunt for a good and easy solution seems to be failing, and I was getting my hopes up about not having to publish to npm and rely on npm-based JS CDNs.
5 Replies
Publishing a JSR package with browser compatibility involves ensuring that your package is written in a way that conforms to the standards expected by both Deno and web browsers. The JavaScript Registry (JSR) is designed to interoperate with the existing npm ecosystem and to support a modern, performant, and highly available JavaScript registry experience.
According to the documentation, JSR natively supports publishing TypeScript source code, which is then used to auto-generate documentation for your package. It also supports token-less publishing from GitHub Actions and package provenance using Sigstore. Importantly, JSR packages can be seamlessly consumed by any tool that uses
node_modules/ folders, which means they can be incrementally adopted in Node projects. However, the documentation also emphasizes that JSR packages can be imported using HTTP imports, like browsers and Deno do.
To ensure browser compatibility, you should follow these guidelines:
1. Write your module using modern tooling like TypeScript, which is supported by JSR.
2. Ensure that your code follows the ESM (ECMAScript Modules) format, as this is the standard module system supported by modern browsers.
3. Use explicit file extensions and paths in your import statements to avoid resolution issues.
4. When publishing, use the jsr publish or deno publish command, which will inspect your code and rewrite any imports that require probing to resolve, ensuring a consistent format that does not require probing.
The documentation mentions that during the publish process, the publishing tool will locally rewrite import statements to remove the need for probing during resolution. This means that all relative imports must have explicit extensions and paths, and any bare specifiers must be resolvedto explicit names and version constraints.
For browser compatibility, it's important to note that while JSR packages can be imported directly using HTTP imports, you may still need to consider the use of a CDN for efficient delivery of your package to web clients. The documentation does not explicitly mention a specific CDN to use for JSR packages in browsers, but it does imply that JSR packages should be consumable in a way that is compatible with web standards.
If you are looking for a CDN to serve your JSR packages to browsers, you might consider using a service like Skypack or jsDelivr, which can serve npm packages as ES modules directly to browsers. These services typically handle the conversion and optimization of packages for browser use.
Remember that while JSR aims to provide a better experience than npm for package authors and users, it is still important to test your package in the environments you intend to support, including browsers, to ensure compatibility. If you encounter any issues or have specific requirements for browser compatibility that are not addressed by JSR, you may want to reach out to the JSR community or file an issue for further assistance. 🦕
Helpful Links:
Why We Added package.json Support to Deno
Building modules with Deno
How to publish Deno modules to NPM
dnt — the easiest way to publish a hybrid npm module for ESM and CommonJS
Announcing the Web-interoperable Runtimes Community Group
Deno 1.28: Featuring 1.3 Million New Modules
How we built JSR
thank you bot, but this isn't really helping my case :nikopensive:
Browser compatibility is still in the works
you can still try to import your module in the browser using esm.sh
for example
import {parse} from https://esm.sh/jsr/@std/csv@0.224.0Oh, that's interesting, so far the documentation I saw of esm.sb didn't mention JSR at all
ok, after looking a bit into it it's actually the thing I needed, perfect!