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

121–130 of 183 posts

Re: JSR: The JavaScript Registry

#121

Post by digging »

pier25 wrote: post #114
digging wrote: post #93

Earlier quoted context omitted.

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.

Oh, yes, that makes more sense.

Still, native typing is not even on the horizon for ES, so I think my point stands for businesses that are heavily invested in supporting TS. TS is what we need today, it doesn't make sense to ignore it because theoretically it could be obsolete in 5-10 years.

Re: JSR: The JavaScript Registry

#122

Post by lucacasonato »

seniorsassycat wrote: post #90
mhagemeister wrote: post #74

Earlier quoted context omitted.

> 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

- `isolatedModules: true` is required - Decorators: standard spec decorators only - JSX: tsconfig options are lifted into JSX pragma comments on publish (configuration goes into code so that consumers can emit based on these options still)

TypeScript has very very few options that affect emit, and effectively everyone has settled on one subset now.

Re: JSR: The JavaScript Registry

#123

Post by lucacasonato »

seniorsassycat wrote: post #91
lucacasonato wrote: post #66

Earlier quoted context omitted.

Look at the comment under the comment you mention - those issues are about the TS type system, NOT the TS syntax. TS syntax is highly stable, and is the only thing JSR relies on :)

How is that true if the npm compatibility layer serves compiled js and .d.ts files?

Both `.d.ts` and `.js` files can be created without understanding the TS type system (this is what JSR does). Creating both of those is just a TS syntax transform - one that is highly stable (esbuild and friends all do it already).

Re: JSR: The JavaScript Registry

#124

Post by WorldMaker »

fhd2 wrote: post #73

Oh boy. Reading the title ("JSR: The JavaScript Registry" at the time of writing) I had high hopes this might be what I'm looking for: Dependency management for JavaScript in the browser. It's something entirely different. I tried to look for something lately that: 1. Makes it easy to download specified versions of JS libs. 2. Exposes these libs as proper ES6 modules. I get why (2) is a bit tricky, it'd be fantastic…

You can just use npm and ship node_modules on your website. It's probably "huge" so you probably want to clean out dev dependencies first (`npm prune --omit=dev` is one way to clean that) and you might find it useful to search for big binaries to filter out and redundant directories that you don't need (libraries that still include all of UMD and CommonJS and ESM builds even though you only need one), and there may still be libraries that don't directly load in the browser and you need to spot bundle with a tool like esbuild to a vendor directory.

Mostly the only other glue you need after that is an import map.

I find this flow useful (ship an optionally pruned node_modules, spot build specific vendor libraries, add import map), especially for lightweight development/testing, and so I did document it specifically from start to finish for one of my libraries (which is sort of a "framework"), it includes a vendor build one-liner:

https://worldmaker.net/butterfloat/#/getting-started?id=setu...

(The Example section after the Dev Environment one shows the import map at the top of the example HTML if you are looking for that. I forgot that's where it was when re-reading this.)

Re: JSR: The JavaScript Registry

#125

Post by lucacasonato »

WorldMaker wrote: post #117
lucacasonato wrote: post #82

Earlier quoted context omitted.

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

Doesn't this get us right back to where we started from? Where you don't want users to be able to register arbitrary names :)

Re: JSR: The JavaScript Registry

#126

Post by simpaticoder »

kwhinnery wrote: post #118
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.…

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

Re: JSR: The JavaScript Registry

#127

Post by wruza »

WorldMaker wrote: post #115
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…

Where can one read up on [2.]?

Re: JSR: The JavaScript Registry

#128

Post by WorldMaker »

pier25 wrote: post #63
imbnwa wrote: post #4

Man, if only they'd debuted with this, but, hindsight and all. My only thing is that TypeScript has no spec, standard, or competing implementations so it seems a bit risky to treat it as a first-class citizen as far as publishing packages goes.

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.

Technically ES did introduce types already: in the "lost version" ES4. Typescript's syntax was partially inspired from ES4 and while not "compatible" with the previous type system there is more compatibility in the syntax than you might expect.

The Type Annotations [0] proposal that TC-39 (in charge of ES standardization) has kept in front of them (at Stage 1 so far) takes the "Python approach" of standardizing the syntax but not the type system still leaving that to external tools (in part because of the lessons from the mistakes of ES4 and the type system that was standardized but never really adopted). The proposal basically assumes that most types will (still) be in the Typescript type system (and would still need Typescript or compatible tool to type check) and maximal (but not complete) compatibility with Typescript syntax is a goal of the proposal.

But you don't don't have to take my word on that, the FAQ at the bottom of that Type Annotations proposal is well written and quite detailed.

[0] https://github.com/tc39/proposal-type-annotations

Re: JSR: The JavaScript Registry

#130

Post by WorldMaker »

lucacasonato wrote: post #125
WorldMaker wrote: post #117

Earlier quoted context omitted.

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

Doesn't this get us right back to where we started from? Where you don't want users to be able to register arbitrary names :)

Correct. That's a big part of why it was a joke. (It's also a contributing factor in why I wonder if golang itself is in fact a prank.)
Post reply on HN