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

51–60 of 183 posts

Re: JSR: The JavaScript Registry

#51

Post by TheFuzzball »

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.

Re: JSR: The JavaScript Registry

#52

Post by joshmanders »

kwhinnery wrote: post #32
h43z wrote: post #19

Everything just has to sound cool these days because yolo yarn dlx jsr add @oak/oak

That does get to be a mouthful! But if you wanted, you can of course do: yarn global add jsr so that subsequent installs could just be: jsr add @oak/oak

I still find `npm install @oak/oak` better.

Re: JSR: The JavaScript Registry

#54

Post by itslennysfault »

diggan wrote: post #39

> JSR: The JavaScript Registry Then on the website: > Made for TypeScript & ESM > JSR is designed for TypeScript > You publish TypeScript source Seems the tag needs an update to reflect what this really is :)

and the name... I suggested TSR (the TypeScript Registry)

Re: JSR: The JavaScript Registry

#56

Post by tomalbrc »

diggan wrote: post #39

> JSR: The JavaScript Registry Then on the website: > Made for TypeScript & ESM > JSR is designed for TypeScript > You publish TypeScript source Seems the tag needs an update to reflect what this really is :)

The project is called "The JavaScript Registry"

> The JavaScript Registry (JSR) is a modern package registry for JavaScript and TypeScript.

https://jsr.io/docs/introduction

Re: JSR: The JavaScript Registry

#57

Post by [deleted] »

diggan wrote: post #39

> JSR: The JavaScript Registry Then on the website: > Made for TypeScript & ESM > JSR is designed for TypeScript > You publish TypeScript source Seems the tag needs an update to reflect what this really is :)

[deleted]

Re: JSR: The JavaScript Registry

#58

Post by diggan »

tomalbrc wrote: post #56
diggan wrote: post #39

> JSR: The JavaScript Registry Then on the website: > Made for TypeScript & ESM > JSR is designed for TypeScript > You publish TypeScript source Seems the tag needs an update to reflect what this really is :)

The project is called "The JavaScript Registry" > The JavaScript Registry (JSR) is a modern package registry for JavaScript and TypeScript. https://jsr.io/docs/introduction

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

Re: JSR: The JavaScript Registry

#59

Post by apitman »

selfmodruntime wrote: post #50
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?

You can't, and for good reason. Deno has slightly different API's than Node. Bun also has subtle differences between their STL implementation and Node's, but afaik, they're getting there.

I think maybe I was unclear. I'm talking about writing libraries that abstract across these differences and provide a single API, as sibling describes. I already know it's possible. I made a simple filesystem abstraction here[0] and a very simple HTTP library that uses it here[1]. They both work in Node/Deno and the browser. Unfortunately I ran into issues with Bun's slice implementation[2], but that should be fixed eventually.

My overall question is that I suspect there's a much better way of detecting and using the different backends, and I'm wondering what techniques are out there.

[0]: https://github.com/waygate-io/fs-js

[1]: https://github.com/waygate-io/http-js

[2]: https://github.com/oven-sh/bun/issues/7057

Re: JSR: The JavaScript Registry

#60

Post by deredede »

lucacasonato wrote: post #47
postalrat wrote: post #46

Earlier quoted context omitted.

I'd suggest they require a DNS entry to use a scope and all scopes have a one to one relationship with a domain.

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).
Post reply on HN