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

JSR Is Not Another Package Manager

deno.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: JSR Is Not Another Package Manager

#11

Post by Philip-J-Fry »

I think true innovation here would be forgoing a centralised package registry and just using good old file systems. Go modules have the the right idea, pull a package from a server which responds to basic HTTP requests or even a file system. If you want some smart searching capability, or generated docs then create a proxy which packages are downloaded through which allows you to index them.

Just take things back to basics. You shouldn't have to publish a package on some centralised registry, you should just be able to import a package from anywhere.

Re: JSR Is Not Another Package Manager

#12

Post by chrisldgk »

Though I‘m not sure if it will get adopted by as many people as NodeJS (and other kind-of drop-in replacements like Bun) did, I‘m really excited by the innovation that Deno brings to the JS/TS space. Particularly actually looking at the hassles that working with NodeJS currently brings and trying to find elegant solutions to that is an admirable goal. If Deno doesn‘t get adopted by many people, maybe at least some of these ideas can later find their way into other runtimes.

As anyone that has tried to publish hybrid packages that include types, a CJS and an ESM version, all the while maintaining semver and anything else can be a real hassle. Everyone seems to have a different solution, and most of the time you end up writing a convoluted build system for your package consisting of an amalgamation of tsc, esbuild, rollup or whatever other bundler is the hot new stuff.

Re: JSR Is Not Another Package Manager

#13

Post by chrisldgk »

mike_hearn wrote: post #4

What's the business model, I wonder? The reason npm registry didn't evolve much is that it is expensive to give away cloud services and eventually got sold to Microsoft, who presumably assessed that adding features wouldn't drive much extra revenue. How many people publish private packages to npmjs.com how much does it cost to host and serve the ever growing collection, especially as they're pretty lenient about peop…

While I haven’t tried it myself yet, I remember finding nest.land[1] and thinking decentralization is a beautiful approach to something as centrally important to the JS development world as packages are.

I also remember thinking it‘s the first and only thing I‘ve ever seen where using the blockchain as the technical basis for it makes sense and isn‘t tacked on for grfiting purposes.

[1] https://nest.land

Re: JSR Is Not Another Package Manager

#14

Post by chrisldgk »

wwwigham wrote: post #10
mike_hearn wrote: post #4

What's the business model, I wonder? The reason npm registry didn't evolve much is that it is expensive to give away cloud services and eventually got sold to Microsoft, who presumably assessed that adding features wouldn't drive much extra revenue. How many people publish private packages to npmjs.com how much does it cost to host and serve the ever growing collection, especially as they're pretty lenient about peop…

> What's the business model, I wonder? Serverless functions, right? That's what deno deploy is billed as. Presumably the registry is a platform-adjacent investment to try and bring more serverless market-share to deno. Since it provides a npm-registry compatible facade, presumably you should feel safe publishing deno-y code to it (without calling platform APIs?), and should thus be more likely to use deno, and thus e…

I believe you hit the nail on the head there.

That, together with the fact that you can still host the deno runtime on your own hardware actually makes it a pretty viable alternative to new projects that you would be building using NodeJS otherwise, with the added bonus that if you ever decide to go serverless, you don‘t have to rewrite your code since you can take the same codebase and move it to deno deploy (or supabase functions, which just uses deno under the hood itself)

Re: JSR Is Not Another Package Manager

#15

Post by ManBeardPc »

Philip-J-Fry wrote: post #11

I think true innovation here would be forgoing a centralised package registry and just using good old file systems. Go modules have the the right idea, pull a package from a server which responds to basic HTTP requests or even a file system. If you want some smart searching capability, or generated docs then create a proxy which packages are downloaded through which allows you to index them. Just take things back to…

Bazel also allows to pull dependencies from different sources via Bzlmod.

1. define dependency like bazel_dep(name = "protobuf", version = "3.19.0") 2. define repositories where to look for it

A repository is just a file structure like /modules/$MODULE/$VERSION + some info about the module. Can be on a HTTP server or just on your local file system.

https://bazel.build/external/overview#bzlmod

I hope more tools adopt something similar. Or maybe a single package manager for everything, so we can finally build cross-language software without having to debug why tool A can't find stuff from B.

Re: JSR Is Not Another Package Manager

#16

Post by norman784 »

mike_hearn wrote: post #4

What's the business model, I wonder? The reason npm registry didn't evolve much is that it is expensive to give away cloud services and eventually got sold to Microsoft, who presumably assessed that adding features wouldn't drive much extra revenue. How many people publish private packages to npmjs.com how much does it cost to host and serve the ever growing collection, especially as they're pretty lenient about peop…

> What's the business model, I wonder?

I think this video[0] answers that question, overall I think the video is interesting if you have time to watch it entirely.

[0] https://youtu.be/dHfZiqVWVhk?si=RqEmPmizm7Rs_91V&t=2779

Re: JSR Is Not Another Package Manager

#17

Post by mort96 »

eqvinox wrote: post #6

Sure, it's not a "Package Manager" by JavaScript nomenclature, where apparently the package manager refers only to the client side piece. Instead it's apparently a "Package Manager" and a "Package Registry"… which most other environments just call a "package manager". As a non-JavaScript developer, drawing this distinction feels incredibly silly to me…

I mean the exact same distinction is drawn in the Linux space: dpkg/apt and pacman and dnf and opkg are package managers, while Debian's repos and Ubuntu's repos and Arch Linux's repos and Alpine's repos and Fedora's repos and Red Hat's repos are "package registries". It's a natural distinction to draw IMO, even if some tools have a hard-coded "package registry" URL.

Re: JSR Is Not Another Package Manager

#18

Post by mort96 »

posix_monad wrote: post #9

TypeScript is not a good foundation to be building on. The language has very complex semantics and the only "spec" is the main implementation, which is also evolving.

Yet it's the best we have at the moment in terms of statically typed JS (other than JSDoc which encodes the type system in comments, which .. has its own issues).

Re: JSR Is Not Another Package Manager

#19

Post by fire_lake »

ManBeardPc wrote: post #15
Philip-J-Fry wrote: post #11

I think true innovation here would be forgoing a centralised package registry and just using good old file systems. Go modules have the the right idea, pull a package from a server which responds to basic HTTP requests or even a file system. If you want some smart searching capability, or generated docs then create a proxy which packages are downloaded through which allows you to index them. Just take things back to…

Bazel also allows to pull dependencies from different sources via Bzlmod. 1. define dependency like bazel_dep(name = "protobuf", version = "3.19.0") 2. define repositories where to look for it A repository is just a file structure like /modules/$MODULE/$VERSION + some info about the module. Can be on a HTTP server or just on your local file system. https://bazel.build/external/overview#bzlmod I hope more tools adopt…

Bazel mod requires a registry of packages in a git repo, so it’s quite centralized.

Re: JSR Is Not Another Package Manager

#20

Post by postepowanieadm »

posix_monad wrote: post #9

TypeScript is not a good foundation to be building on. The language has very complex semantics and the only "spec" is the main implementation, which is also evolving.

And has some really odd behaviors like https://github.com/microsoft/TypeScript/issues/17053
Post reply on HN