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

161–170 of 183 posts

Re: JSR: The JavaScript Registry

#161

Post by mhagemeister »

seniorsassycat wrote: post #139
lucacasonato wrote: post #123

Earlier quoted context omitted.

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

I know .is can be emitted as an ast transformation, but I'm surprised by d.ts files. Even inferred types?

We do some basic inference, but that's why we require explicit return types in the public API, see https://jsr.io/docs/about-slow-types . TypeScript itself will ship with a new `isolatedDeclarations` option in the next release which is the same thing. The point is that no inference other than simple literal inference needs to be done to get the type of the public API. That way generating .d.ts files can be done by any tool by merely looking at the syntax without type inference.

Re: JSR: The JavaScript Registry

#162

Post by mhagemeister »

AgentME wrote: post #146
m3h wrote: post #92

Earlier quoted context omitted.

Thank you. I stand corrected on some points. The messy ecosystem of npm, yarn, pnpm, JS, TS, ES, and ESM has all cost me a good amount of white hair. A good source of my confusion came with not immediately recognizing that a new package registry does not require a new package manager to work with. I think the "jsr" commands in the code samples and the jsr.json make it feel like there's a new package manager in play h…

As far as I can tell, the "npx jsr add @luca/flag" command given for using JSR with Node itself calls "npm i @luca/flag@npm:@jsr/luca__flag" and is equivalent. You get a normal node_modules+package.json+package-lock.json output that the npm command is fully able to work with. It looks like JSR re-publishes all of its packages translated into JS + .d.ts files onto npm under the @jsr scope. Regular npm packages have no…

yup, we added the `jsr` tool mostly so that you don't have to be aware of the @jsr scope that's used under the hood. We're not publishing to npm though, but rather mapping the @jsr scope to the JSR registry in the project's .npmrc file.

Re: JSR: The JavaScript Registry

#163

Post by mhagemeister »

apitman wrote: post #111
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?

The performance of type inference matters for runtimes which work with TypeScript files directly, rather then using the transpiled .js + .d.ts files like Deno. This has several benefits in that we can jump to the source on "go to definition" rather than some random .d.ts file among other things. Deno uses the original TS files for type checking as well and that's why inference also affects type checking performance in some runtimes.

By ensuring explicit return types in the public API, the generation of .d.ts files is turned into a mere syntax transform, rather than requiring the tsc compiler. This is something TypeScript will ship with in the next release itself. They're adding a new `isolatedDeclarations` option which is the same thing.

Re: JSR: The JavaScript Registry

#164

Post by mhagemeister »

smusamashah wrote: post #131

Is there a similar site but for browser only javascript libraries? I am not a web developer, and always find NPM etc way too much for my occasional needs. When I search internet for anything, 90% of the times I get an NPM based library that can not work in browser with just a . JavaScript has improved a lot and does not really need Node/compilation steps for almost all my use cases. Is there anything where I can sear…

I think you're looking for esm.sh . It transpiles both npm and jsr packages for the browser so that they can be used in a simple script tag.

Re: JSR: The JavaScript Registry

#165

Post by mhagemeister »

seniorsassycat wrote: post #99
tentacleuno wrote: post #29

This is great! I very much like the added TypeScript support (which the standard NPM registry does not have.) and that it's open-source. I'll see about getting my packages uploaded onto here, too -- just having built-in support for TypeScript makes packaging x100 easier. Regarding NPM, it's absolutely insane that we've been depending upon a closed-source, monolithic nightmare with poor UX for so long. You can't even…

I'm not sure jsr fixes comments in package.json, and I wouldn't blame npm for the miss feature. package.json is used at runtime by node.js and strictly parsed as json. Npm or just could strip comments on publish, but local development of the package would break. Not sure if bun or demo use pjson at runtime or if they allow comments. I think it's interesting that JavaScript projects at the package root despite most pr…

> I'd like tool to generate the whole package root, including a transpiled or generated package.json

That's exactly what JSR does. We generate the package.json ourselves.

Re: JSR: The JavaScript Registry

#166

Post by int_19h »

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.

If and when it does, why do you think it wouldn't just be a subset of TS? Why reinvent the wheel when you have a perfectly good one that's beed around for 12 years and is proven in production?

Re: JSR: The JavaScript Registry

#167

Post by deredede »

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

Not if the system is built for DNS first. If a company/individual/organisation has a domain name, they are expected to use the domain. It is much less of an issue if someone has kik.users.registry.com when the company publishes packages under kik.com.

Re: JSR: The JavaScript Registry

#168

Post by ascorbic »

TheFuzzball wrote: post #51
apitman wrote: post #44

Seeing Bun/Node/Deno support reminds me of a question: are there any good resources on writing JS that works in all 3 and the browser? For example if I wanted to write a simple filesystem API that would work the same across bunodeno?

I think you'd have to write a facade package with a consistent API that mapped to the node/deno/bun equivalents, since they're each quite different. Best bet is to use the Node fs package and rely on the deno/bun compatibility layer. More generally, Deno pushes for Web Platform APIs, and as more are proposed and implemented the runtime-specific APIs will become fewer and fewer.

If you use Node 20+ then there's a lot more compatibility with web platform APIs, so it is possible to write code that works on Node, browser and WinterCG-compatible runtimes like Deno. Obviously you'll need to avoid using Node builtins.

Re: JSR: The JavaScript Registry

#169

Post by ascorbic »

WorldMaker wrote: post #128
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.

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…

I used ActionScript 3 back in the noughties and was so excited for ES4 in the browser. Adobe open-sourcing Tamarin made it seem it was a done deal (I didn't follow the politics). I was so disappointed when it was killed. It did mean that when I tried Angular 2 the best part of a decade later I was delighted with how familiar TypeScript felt.

Re: JSR: The JavaScript Registry

#170

Post by seniorsassycat »

mhagemeister wrote: post #165
seniorsassycat wrote: post #99

Earlier quoted context omitted.

I'm not sure jsr fixes comments in package.json, and I wouldn't blame npm for the miss feature. package.json is used at runtime by node.js and strictly parsed as json. Npm or just could strip comments on publish, but local development of the package would break. Not sure if bun or demo use pjson at runtime or if they allow comments. I think it's interesting that JavaScript projects at the package root despite most pr…

> I'd like tool to generate the whole package root, including a transpiled or generated package.json That's exactly what JSR does. We generate the package.json ourselves.

In development, or on publish?
Post reply on HN