from Hacker News

JSR Is Not Another Package Manager

by sbt567 on 4/25/24, 4:03 AM with 54 comments

  • by lrvick on 4/25/24, 12:23 PM

    "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

  • by Philip-J-Fry on 4/25/24, 9:12 AM

    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.

  • by mike_hearn on 4/25/24, 8:07 AM

    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 people serving large binaries from it?

    The Java world got burned by this a few years ago when JFrog shut down Bintray, which had been the second largest open source package repository after Maven Central. A ton of stuff had to be republished, a ton of build configs updated. Now Maven Central is hopefully Too Big To Fail and Sonatype is a sustainable independent business, partly due to the widespread practice of companies buying its Nexus product to mirror Central internally, something I haven't seen so much of in the JS space, and partly because the Java ecosystem doesn't tend to host giant binaries off it. But still.

    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.

  • by chrisldgk on 4/25/24, 9:25 AM

    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.

  • by pjmlp on 4/25/24, 7:39 AM

    Based on similar experience from other language ecosystems since Perl introduced CPAN, unless a customer requires me to use JSR, I am not rely convinced to stay away from npm repos.

  • by eqvinox on 4/25/24, 8:29 AM

    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…

  • by thenerdhead on 4/25/24, 2:03 PM

    I like how they encourage best practices using a score similar to pub.dev & what npm tried to do years ago. Also the compatibility portion is quite interesting given the evolution of runtimes.

    I suppose I don't quite understand the rationale of another registry. But perhaps that is what is needed nowadays with various ecosystems and their chosen defaults. What for example prevents npm from adopting ES modules tomorrow? (Although there are many opinions on CommonJS/ES Modules)

  • by posix_monad on 4/25/24, 9:02 AM

    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.

  • by dinckelman on 4/25/24, 10:42 AM

    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

  • by nailer on 4/25/24, 2:07 PM

    > higher scores are awarded to packages that include comprehensive JSDoc documentation on each exported symbol

    Nope. I love Ryan Dahl, but code filled with JSdoc comments that needlessly replicate type information already in the code, and mandatory descriptions for every variable (often used as a substitute for proper naming) has a really low signal:noise ratio.

  • by hamilyon2 on 4/25/24, 11:45 AM

    Well of course. JSR is java specification request.

  • by thriftwy on 4/25/24, 7:58 AM

    I thought that JSR is an RFC for Java - can we please be more creative than reusing TLAs?

    Call it Genet.