aube, a fast Node.js package manager
16 points by roryokane
16 points by roryokane
aube uses the same on-disk model as pnpm [...] but the install pipeline is written in a faster, natively-threaded language instead of JavaScript.
I would like to say that this should make a difference, but should it? pnpm already does something clever with the "on-disk model", but IMO the biggest bottleneck is always the network connection.
Use existing lockfiles.
This is really a good feature. Much like jj, nobody needs to know that you are not using npm.
Unfortunately I does not mention compatibility with configuration from other tools, but it's a nit pick for sure.
Edit after five minutes of use. It has a nice ui compared to npm. After installing dependencies, it warned about some of them that were not allowed to run build scripts (e.g. esbuild). It also warned me that it was installing dependencies that were not expected for my current platform. The only hippuc is with a local dependency. At work there's a monorepo and the main web project relies on a separate utilities project that resides in another directory. I had to remove my package-lock or otherwise aube would try to search for the literal project name in npm registry.
This tool is by @jdx, the author of mise and other tools. I learned of it from jdx’s newest blog post, Going Full Time on Open Source.
Is jdx doing all this solo or are they a team? Some of these tools seem quite a big lift to be done properly. I like mise (especially over asdf) but it seems like he is spreading himself thin with all these various tools.
[Not trying to be a downer, just curious]
I had a similar thought when I saw aube - but looking at the repo it looks like aube at least is developed with help from an LLM.
I miss a section on motivation in the readme for aube; I'm guessing it's mainly about being less insecure by default than existing js package managers?
I'm guessing it's mainly about being less insecure by default than existing js package managers?
Even though the author definitely earned a good dose of trust with their other open source projects, I'd trust long-tenured, actively maintained tools more than a vibe-coded one (if that's indeed the case¹).
Plus, in my understanding security problems in the js ecosystem are much more about the package registry than the existing package managers.
¹ https://slop-o-meter.dev/endevco/aube says it's picking up some slop, but not too badly actually. It's not a very reliable measure, though. The landing page's style screams LLM.
in my understanding security problems in the js ecosystem are much more about the package registry than the existing package managers.
Well, yes and no. It's the combination of not being able to trust the registries combined with the defaults of happily running code they provide (eg: build scripts).
Turns out there's more information in the docs, than the readme: