Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSR: The JavaScript Registry

jsr.io

Post reply on HN
Print view View original

81–90 of 183 posts

Re: JSR: The JavaScript Registry

#81

Post by seabass »

When would I want to use JSR? The "Why JSR?" section simply says JSR is a superset of NPM that can be used with any javascript package manager. But NPM itself can also be used with any javascript package manager as far as I know. It seems like the benefit they're trying to add is strict type support for packages, but the fact that it's a superset of NPM means all existing packages that lack types are still supported by JSR. So, what benefit is so great that it's worth segmenting the ecosystem?

Side rant: not at all a fan of the decision to punish libraries ("slow types") that use type inference by reducing their score.

Re: JSR: The JavaScript Registry

#82

Post by lucacasonato »

deredede wrote: post #60
lucacasonato wrote: post #47

Earlier quoted context omitted.

What happens if the domain registration expires? Scope takeover?

Domain expiration is rare, and virtually only happens when the related projects are dead anyways; freeze existing packages (no more updates until the original key for the domain comes back online, with manual override by registry administrators for edge cases) and have a reasonable waiting period (a couple of months to a year) before allowing the new owner to use the namespace (with different project names within).

How do you deal with individuals that may not have a domain? What do you tie their scope to?

Re: JSR: The JavaScript Registry

#84

Post by nerdponx »

kwhinnery wrote: post #33
MatthiasPortzel wrote: post #27

> JSR isn't a replacement for the npm registry; it's a superset of npm. I first read this line to mean that JSR contains every package on NPM, and was just doing some post-processing on them. But it does seem to be its own registry. Maybe the intent of the line was to communicate that you can install packages from both?

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.

That's not really what "superset" means, so I think you might want to change the wording.

Re: JSR: The JavaScript Registry

#85

Post by jmull »

After reading the "Why JSR?" article I still don't understand why this exists.

It looks like it has a few niceties but also some limitations. To catch on you need to convince some significant segment of both package publishers and consumers to switch to it. That means there needs to be some killer feature they just can't get with the existing registries, and I'm not seeing anything like that.

Re: JSR: The JavaScript Registry

#88

Post by grodriguez100 »

kwhinnery wrote: post #33
MatthiasPortzel wrote: post #27

> JSR isn't a replacement for the npm registry; it's a superset of npm. I first read this line to mean that JSR contains every package on NPM, and was just doing some post-processing on them. But it does seem to be its own registry. Maybe the intent of the line was to communicate that you can install packages from both?

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.

> I think this is mostly right - "superset" in that JSR modules can depend on npm modules

This is not what most people would think when a registry is said to be a “superset” of another.

Re: JSR: The JavaScript Registry

#89

Post by seniorsassycat »

Vinnl wrote: post #76
diggan wrote: post #58

Earlier quoted context omitted.

Yeah, this is what I'm complaining about. If you're building something that is designed for TypeScript , made for TypeScript and publishes TypeScript sources, then I find it really hard to understand why you'd name it "The JavaScript Registry".

Presumably because they don't want to imply that it won't work if you don't use TypeScript.

I don't think it will, unless you use the npm compatibility layer.

Re: JSR: The JavaScript Registry

#90

Post by seniorsassycat »

mhagemeister wrote: post #74
m3h wrote: post #62

As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled…

> This makes the already complicated module resolution logic in most bundler/packaging tools even more complicated as they must account for the intricacies of another package manager. A house of cards being stacked on another house of cards... JSR is a registry, not a package manager. npm allows you to add multiple registries and JSR provides an npm API endpoint. From npm's point of view packages coming from JSR are…

I'm really curious how you handle typescript versions and options that affect emit
Post reply on HN