[kwhinnery]

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.

[simpaticoder]

Sounds like a good value prop. One thing that I'm hoping is to reduce dependency on a single private company, npm inc., in publishing and distributing modules. But you didn't list this as a value prop. (I notice other posters are upset at the 'fragmentation' of module distribution, but I see this as a strength, not a weakness.)