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

111–120 of 183 posts

Re: JSR: The JavaScript Registry

#111

Post by apitman »

seabass wrote: post #81

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…

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

Do you feel that using type inference doesn't actually reduce performance, or just that it's not a big enough problem to warrant a reduced score?

Re: JSR: The JavaScript Registry

#112

Post by kwhinnery »

warpech wrote: post #43
kwhinnery wrote: post #3

Kevin from the Deno team here - happy to answer any questions you have today!

I am not a user of Deno, but I acknowledged that HTTPS module imports were one of the original selling points of Deno compared to Node/NPM. Was it revised at some point that a package repository is needed? What's the back story?

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

Re: JSR: The JavaScript Registry

#113

Post by seniorsassycat »

Vinnl wrote: post #103
seniorsassycat wrote: post #89

Earlier quoted context omitted.

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

An npm compatibility layer doesn't sound like it has anything to do with TypeScript? I'm assuming that you can use JavaScript anywhere you can also use TypeScript.

The jsr registry serves typescript, so you have to use typescript tooling, maybe tsc buxy could be esbuild, demo, w/e.

The npm compatibility layer compiles typescript to JavaScript on the registry so you can use it without any typescript tooling.

Re: JSR: The JavaScript Registry

#114

Post by pier25 »

digging wrote: post #93
pier25 wrote: post #63

Earlier quoted context omitted.

I'm still surprised by so many projects betting on TS. ES will introduce types at some point and all this effort around TS will again divide the JS community.

Is that a good reason to write in raw JS today? I'm not betting anything on TypeScript. It was released 11 years ago, and it's incredibly valuable to me. If it takes another 5 years for ES to implement first-class types, and it's a good implementation, I'll start using ES for new work at that time. What's lost here? TS won't just stop compiling.

I'm not referring to end users like yourself but projects like Deno who have invested a fair amount of resources into supporting TS.

Re: JSR: The JavaScript Registry

#115

Post by WorldMaker »

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…

In addition to some of the other answers already:

1. The focus on typescript and typings distribution is useful/interesting for the "promise" that all packages in the registry have typings. If you can trust that every package in JSR has types then you avoid/simplify that current cycle of: npm install a package, find out it doesn't have types, try to install a package of the same name with @types/ in front of it, find out it doesn't exist, look for an alternative library with types or write your own types or give up and `declare module "thatpackagename"` any-type it.

2. Just because "most" production websites do bundling doesn't mean that needs to still be the status quo in 2024. Bundling is increasingly a "premature optimization" and you might not need it. It can be worth investigating if your site/app works well enough with just ESM delivered straight to browsers in 2024 versus what you "gain" from bundling. You might be surprised at how well current browsers can load ESM and the optimizations they already do for you. But even if you do still need bundling ESM is a huge advantage over other formats (especially CommonJS) and every current bundler produces better, more optimized output the more ESM you provide. Their outputs also increasingly look like ESM, and if that isn't the current default it is the "soon" default. esbuild in particular (which also backs some of vite's tools and others) has an ESM bundle output that is delightful, isn't yet the default ("soon") but is a simple "format" switch away. Those ESM bundles are great in today's browsers. ESM matters a lot to bundlers, bundlers are increasingly ESM in their internals and output. Browsers are great with ESM. The "web-standard" part is pretty meaningful today and getting stronger.

Re: JSR: The JavaScript Registry

#117

Post by WorldMaker »

lucacasonato wrote: post #82
deredede wrote: post #60

Earlier quoted context omitted.

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?

This is a joke: GitHub account name. If it is good enough for Golang, …

Re: JSR: The JavaScript Registry

#118

Post by kwhinnery »

seabass wrote: post #81

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…

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.

Re: JSR: The JavaScript Registry

#119

Post by jarodreyes »

kwhinnery wrote: post #112
warpech wrote: post #43

Earlier quoted context omitted.

I am not a user of Deno, but I acknowledged that HTTPS module imports were one of the original selling points of Deno compared to Node/NPM. Was it revised at some point that a package repository is needed? What's the back story?

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, ca…

This is a solid reason to build it. Makes sense to me.

Re: JSR: The JavaScript Registry

#120

Post by postalrat »

lucacasonato wrote: post #82
deredede wrote: post #60

Earlier quoted context omitted.

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?

Subdomains on a service that will do authentication for cheap or free?

Your packages could be published for lucacasonato.imbroke.com

Post reply on HN