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

21–30 of 56 posts

Re: JSR Is Not Another Package Manager

#21

Post by fire_lake »

chrisldgk wrote: post #13
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

Who pays for hosting? The site claims it’s free but I read that as unsustainable

Re: JSR Is Not Another Package Manager

#22

Post by ManBeardPc »

fire_lake wrote: post #19
ManBeardPc wrote: post #15

Earlier quoted context omitted.

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.

From the documentation: https://bazel.build/external/registry

> Bzlmod discovers dependencies by requesting their information from Bazel registries: databases of Bazel modules. Currently, Bzlmod only supports index registries — local directories or static HTTP servers following a specific format.

It just uses the Bazel Central Registry (BCR) by default. You can specify your own via the --registry flag and then it uses them instead. It is possible to specify multiple registries at the same time, so you can mix the official, company internal and on your local filesystem at the same time.

Re: JSR Is Not Another Package Manager

#23

Post by wwwigham »

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…

You can use file:// or git:// versioned dependencies in normal npm `package.json`s today. People just don't, outside some edge cases (local packages, nightly versions) because the centralized registry has upsides for discoverability and maintenance. There's also private registries, where you can setup a .npmrc to pull different namespaces from different registries. But if you want, you can totally be that guy who only publishes their packages to their presumably self-hosted repo - it works.

Re: JSR Is Not Another Package Manager

#24

Post by pjmlp »

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…

Go is exactly how one should not do it, hardcoding SCM URLs on source code, only allowing for source code distribution, and forcing everyone else to jump through hoops to make it work otherwise.

Re: JSR Is Not Another Package Manager

#25

Post by dinckelman »

My motivation to host in this repository completely vanished, the moment I realized that any Zod types are considered slow, and will not produce any type definition on JSR as a result.

On a surface level, they have automatic mechanisms for everything that my projects already have implemented, except it has arbitrary limitations, and not a whole lot of material explaining them properly

Re: JSR Is Not Another Package Manager

#26

Post by pjmlp »

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…

We also use Nexus for .NET, C++, nodejs stuff.

Decentralized approach mostly matters for having a curated repo of what teams are actually allowed to use on their projects, instead of having legal surprised by random devs downloading the Internet into their projects.

Re: JSR Is Not Another Package Manager

#27

Post by eqvinox »

mort96 wrote: post #17
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.

There's one primary tool¹ to access these "package registries" (repositories) though, and it's a 1:n relationship with the tool being generally able to use more than one repository. JavaScript seems to be doing n:1 instead with a whole bunch of frontends to npm.js? And the "special" thing about JSR is that it additionally(?) has its own repo?

Put differently — the tool is the standard, and you have a choice of repos. In JS it's the other way around?

I would describe the JS situation as… hmm… "oddly tilted" in comparison to other ecosystems; the closest thing I can think of is Python's package management situation?

[¹] I'm not counting GUI frontends here, since I'm relatively sure they just call into the same tool.

Re: JSR Is Not Another Package Manager

#28

Post by lifthrasiir »

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…

The fact that Go eventually introduced the central proxy server highlights one of the biggest issues with this approach though: the vast majority of use cases do prefer centralized systems.

Re: JSR Is Not Another Package Manager

#30

Post by [deleted] »

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…

[deleted]
Post reply on HN