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

31–40 of 56 posts

Re: JSR Is Not Another Package Manager

#31

Post by hobofan »

vmfunction wrote: post #8
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…

>Gotta admit, I'd like to see a more decentralized approach become popular here. There's no specific reason packages always have to be hosted in one or two central registries. That is what ESM is. Each https link are basically decentralised registries.

That's what Deno's interpretation of ESM, but nothing inherent to ESM.

The ECMAScript standard doesn't specify the "ModuleSpecifier" further than a string, so how the module specifier is interpreted and loaded may range anywhere from "a handful of well-known modules" to "any retrievable URI".

Re: JSR Is Not Another Package Manager

#32

Post by chrisweekly »

chrisldgk wrote: post #14
wwwigham wrote: post #10

Earlier quoted context omitted.

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

FTR a large and rapidly-increasing percentage of the JS ecosystem supports targeting multiple runtimes. Things like Remix.run, Fastify, Hono, etc. can deploy to Node.js, Deno, Cloudflare workers, etc.

Re: JSR Is Not Another Package Manager

#33

Post by chrisweekly »

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…

They are completely separate concerns! Why would they necessarily be tightly coupled? Assuming use of an npm package registry (the default public one at npmjs.org, or a private one like jfrog artifactory), there's nothing "silly" about using a pnpm client instead of npm (or yarn).

Re: JSR Is Not Another Package Manager

#34

Post by lrvick »

"To publish provenance for a package, you must publish the package from a GitHub Actions workflow."

Read as: "We wish to uphold NPM tradition of not allowing the authors of code to sign their own code, but as an alternative we will increase your package trust score if you build your package with a heavily censored, centralized, and proprietary build system owned by Microsoft"

How is it that STILL the only source for signed javascript packages are Debian apt-get repos. NPM and JSR still have dramatically worse JS supply chain security than a -terrible- 30yo package manager which still requires a lot of custom tooling overhead in every project for reproducible builds (docker, apt package hash pinning, apt-archive, etc).

Oh right, because the NPM team was worried even having -optional- support for package signing would scare off people from publishing javascript packages.

https://github.com/npm/npm/pull/4016

Re: JSR Is Not Another Package Manager

#35

Post by chrisweekly »

eqvinox wrote: post #27
mort96 wrote: post #17

Earlier quoted context omitted.

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

> "relatively sure" Sorry, but you're flat-out incorrect. See e.g. https://pnpm.io/motivation

See also my response to your earlier comment; in the npm ecosystem you can choose your package registry, and your package manager/client, not to mention your target runtime. Coupling any of these distinct concepts is not the norm.

Re: JSR Is Not Another Package Manager

#36

Post by crabmusket »

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…

Deno literally did this[1] in order to be browser-compatible[2], and everybody whinged about it. I happen to love that I can just import an HTTPS URL inside Deno code. It's really nice for playing around with libraries, writing little scripts that pull in dependencies, etc.

[1] https://docs.deno.com/runtime/manual/basics/modules/#remote-...

[2] https://html.spec.whatwg.org/multipage/webappapis.html#modul...

Re: JSR Is Not Another Package Manager

#37

Post by crabmusket »

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…

Rust's Cargo and crates.io are separate, just as another example.

Re: JSR Is Not Another Package Manager

#38

Post by crabmusket »

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

Does JSDoc even have a type checking system? The point of TS is that is actually does something with your declared types. JSDoc is nice... for docs being interpreted by a human. But unless those are used to create red squigglies then it's kind of arbitrary.

I've used JSDoc with TS's type syntax and typechecker in JS files. Which is fine - I find it subjectively uglier but I know some prefer it. But it's still TS that's doing the actual work of determining if all my annotations are compatible when the rubber hits the road.

Re: JSR Is Not Another Package Manager

#39

Post by c-hendricks »

postepowanieadm wrote: post #20
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

Are you saying typescript should parse regular expressions?

Turn on `noUncheckedIndexAccess` and it works as you expect (plus forces you to check all the places you're doing unchecked access).

https://www.typescriptlang.org/play/?noUncheckedIndexedAcces...

Re: JSR Is Not Another Package Manager

#40

Post by davexunit »

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 programs are a nightmare to package for linux distros due to the way they handle dependencies so I would strongly discourage any other language from copying the Go model.
Post reply on HN