Looks awesome, will keep this in mind - every so often you need to create complex documents in code, and it's always a pain. Doing it with a familiar modern programming interface would be nice.
In terms of "when you would use it" - it doesn't necessarily solve a different problem than npm. I think it arguably solves the same problem more effectively (though it is certainly early days and npm still does a lot of things JSR doesn't). I also don't know that we're segmenting the ecosystem, as JSR packages interoperate with npm packages, and you can use one from the other. JSR will end up being additive to npm.
For module authors, we're hoping JSR will be helpful in the following ways:
1.) You can develop and publish TypeScript source, and let JSR handle transpilation and generating .d.ts files for runtimes that don't natively support TypeScript. Especially nice if you are using Deno or Bun (that do natively support TypeScript), and don't have tsc in your workflow otherwise.
2.) JSR generates API docs for you on your package page based on your source code and comments.
3.) JSR has a great DX around publishing packages from GitHub Actions using OIDC (no juggling tokens)
4.) JSR automatically provides provenance for published versions of packages
For module consumers, it helps too:
1.) Compatible with both Deno and existing npm-based projects
2.) Package info and docs provided centralized on the jsr.io site
3.) Quality scores that encourage authors to make their packages fast and well documented
4.) Access to TypeScript source for packages (not just transpiled output)
Absolutely more to be done, but we're hoping that JSR will provide enough extra value to both module authors and consumers that both will prefer to use it when possible.
HTTPS imports will continue to work and be supported in Deno. However, as we observed their usage in the wild, a couple problems became clear:
1.) Duplicated dependencies - projects would often download multiple versions of the same dependency, because there was no deduplication happening based on semantic versions.
2.) Disappearing dependencies - under some circumstances, an HTTPS import URL would be unavailable, causing code dependent on these modules to break.
A central package repository could solve for both of these problems. We considered (and very nearly chose) to just use npm, but it introduced functional and UX problems we wanted to solve for users. So we set about building JSR, and did so in a way that wasn't tightly coupled to Deno (JSR didn't need to be - it is useful in the context of any JavaScript runtime).
Thankfully JSR won't be capable of a left-pad situation where packages can be unpublished - published packages are immutable[1].
As for the potential for disagreements over whether or not a scope should be transferred, that is a big reason why we want to figure out community involvement in governance sooner rather than later. We are gathering potential volunteers who want to discuss becoming a community moderator - if anyone would be potentially interested, they can sign up to join that conversation[2].
This is probably a marketing bug on our part. While we did want to design for TypeScript from the outset, you can definitely happily write and publish plain JavaScript code on JSR. We probably need to do a better job explaining and featuring this.
I think this is mostly right - "superset" in that JSR modules can depend on npm modules, and projects using npm can use the npm registry and JSR together. The bottom line we'd want to communicate is that JSR is additive to npm, and the two can be used at the same time.
We do intend to take a more editorial approach to scopes, and assign scopes to users in a way we think is more intuitive for end users of JSR. We have reserved some obvious scope names already, but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name).
So in the case that a user published "@cocacola/foo", previously published versions of "@cocacola/foo" would remain available indefinitely (unless they were found to be malicious), but we would likely be willing to assign ownership of the "@cocacola" scope to a representative from that brand/company if they asked for it and we could verify their identity. The original author of "@cocacola/foo" would need to publish the module going forward under a different scope.
As JSR develops, you can expect to see more features like those of dnt start to show up in the npm compatibility layer. We've also been exploring how to create a good DX around simultaneously publishing JSR modules to npm, so publishers can control their namespace there as well. We definitely know it's a usage pattern folks are interested in.
In the immediate term, dnt is still a very strong choice for people that want to develop modules in TypeScript using Deno, and then publish them to npm. In the fullness of time, I expect that JSR will provide a pretty complete solution to this problem as well.
I know it's hard to know this since not everyone has access to JSR yet - but it's incorrect to say that adopting JSR (as a module author or consumer) will result in breaking changes. JSR is additive to npm, and can be used alongside npm in existing projects.
Node.js / npm module consumers will be able to use packages published to JSR with minimal differences from packages published to npm. Here's what that will amount to:
- The install command will be different - "npx <jsr command> i @foo/bar" versus "npm i @foo/bar")
- some of the configuration will end up looking different when you inspect it. JSR's npm integration makes use of npm aliases and requires a minor configuration change to .npmrc (that will be done for you by the command to install)
But at the end of the day, JSR is integrating with npm using its existing extension points, not replacing or circumventing it. As a practical matter, your Node.js code that imports dependencies from JSR will look the same as code that imports dependencies from npm. It's all coming from the node_modules folder at runtime.
Whether or not module authors choose to use JSR is more about DX than platform support (JSR works well in Deno and any kind of project that uses a node_modules folder). If as a module author, you would find it useful to:
- Publish actual TypeScript source files to the registry rather than build artifacts
- Have API docs auto-generated for your package from source code
- Use a registry with an explicit goal of being usable across JS runtime environments (rather than being tied to Node specifically)
Then JSR will likely be worth checking out. We'll be opening up JSR to everyone to try soon, so hopefully you can take a look and decide for yourself then :)
Hi there - Kevin from the Deno team here. Thanks for starting this conversation - the recent reduction in regions is part of an ongoing effort to drive down the cost of the platform for customers. We are still learning and iterating as we figure out how to operate the service efficiently. If the new region configuration is causing major problems for you, or might prevent you from considering the service, definitely let us know by sending a message to support at Deno dot com.
Also, we can do better at proactively communicating these changes and releasing doc updates at the same time as rolling out the changes. We will document the current region list ASAP, and revisit how we communicate these changes in the future, so infrastructure configuration changes won’t be surprising.
I think the ecosystem is inching in this direction. There are already some interesting PoCs out there using Tauri (Rust based) and the deno_core Rust crate.
The usage of the word "ideal" in the 2021 post was probably not ideal :)
The accessibility and diverse ecosystem of JavaScript, owing to its status as the lingua franca of software development, would probably be the basis for it being "ideal". I think it would be hard to make an objective claim that one programming language is strictly better than another as a programming language for mathematical ideas.
User-level access control (like ACLs for authenticated users) or something else? Feel free to share longer form thoughts here and I can make sure we keep this concern in mind.
- SDK, REST, and narrative docs in one
- Lots of nice docs features and UI components out-of-the-box
- Built on Astro, so you can hack anything and deploy anywhere