Comments URL: https://news.ycombinator.com/item?id=47224058

Points: 5

# Comments: 0

- 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

Comments URL: https://news.ycombinator.com/item?id=45838267

Points: 15

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=39770793

Points: 5

# Comments: 0

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.

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).

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].

[1] https://jsr.io/docs/immutability [2] https://jsr.io/go/moderator

yarn global add jsr

so that subsequent installs could just be:

jsr add @oak/oak

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.

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.

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 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 :)

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.

EDIT: The docs should now have the full list of regions - https://docs.deno.com/deploy/manual/regions

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.