aube: A Node Package Manager That Installs on the Way to Your Script

The Problem: Install Steps That Slow Down Every Command

Developers in Node projects live with a ritual: pull latest, run install, then run the test. If the install is stale, the test fails with a confusing module-not-found error. aube targets exactly that friction. The README positions it as "Never forget to install." When you run `aubr test` or `aube exec vitest`, aube checks whether node_modules is fresh for the current package.json and lockfile. If not, it installs first. If nothing changed, it skips straight to the script. This removes the separate install step from most daily work. The project is for anyone who runs package scripts often, which is nearly every Node developer. But the broader pitch is for teams that want tighter security defaults without changing their lockfile format. aube reads and writes pnpm-lock.yaml, package-lock.json, npm-shrinkwrap.json, yarn.lock, and bun.lock in place. That means you can try it without forcing your team to migrate package managers.

How aube Decides When to Install

The core mechanism is a freshness check. According to the README, before running a script, aube compares node_modules against the current package.json and lockfile. If dependencies are missing or stale, it installs. If they match, it runs the script directly. This is different from pnpm or npm, where you explicitly run install and then run your script. aube's design makes the install implicit. The README gives the example `aubr test`, where `aubr` is shorthand for `aube run`. You can also run `aube build` or `aube lint` directly, and aube treats them as `aube run <script>` if the script exists. The freshness check is the heart of the speed claim: repeat test commands run up to 21x faster than pnpm and up to 1.9x faster than Bun in the current benchmarks, according to the README. That speed comes from skipping the install entirely when nothing changed, not from making the install itself faster. The install path is also fast, about 6x faster than pnpm and 2x faster than Bun in warm installs, but the repeat-command win is the bigger deal for daily work.

Getting Started: Install and First Run

The recommended install path is mise. Run `mise use -g aube` to install globally. Then check with `aube --version`. Inside a project, you can pin aube with `mise use aube`. aube is also on npm: `npm install -g --ignore-scripts=false @endevco/aube`. The npm package uses an install script to fetch native binaries, so the flag keeps scripts working if your npm config disables them. Homebrew users can do `brew install jdx/tap/aube`. After install, the first run in an existing project is `aubr test`. That command checks freshness, installs if needed, then runs the test script. You also get `aubx` for one-off tools: `aubx cowsay hi` runs a local binary if one exists, or fetches it into a throwaway environment. The `-p` or `--package` flag forces a specific package for the one-off command. For CI, use `aube ci`, which removes node_modules, verifies the lockfile is fresh for package.json, then installs. That is the command to use when the lockfile must be authoritative.

Security Defaults: The Lifecycle Script Jail

aube's security posture is the most distinctive feature. The README claims "the tightest security defaults of any Node.js package manager" and "the only one with a lifecycle-script jail." Out of the box, aube blocks exotic transitive dependencies, waits for approval before running lifecycle scripts, fails trust downgrades at resolve time, and holds brand-new releases in a 24-hour cooling window. The README does not define "exotic" precisely, which is a gap. The lifecycle-script jail is the key part. Many npm packages run postinstall scripts that execute arbitrary code. aube makes those wait for approval. You can also add one line to a config, `paranoid: true`, which turns the soft gates into hard fails and enables the build jail. This is a real trade-off: secure defaults mean more friction for legitimate postinstall builds. The README does not show the exact config file or syntax for `paranoid`, so you would need to check the docs at aube.jdx.dev. But the claim is specific enough to verify.

Lockfile Handling: In-Place Updates vs. aube-lock.yaml

aube does not force a new lockfile format. If a project already has a supported lockfile, aube reads it and writes updates back to the same file. That is a major adoption advantage. You can try aube locally and commit the same pnpm-lock.yaml or package-lock.json without making teammates switch. For a new project with no lockfile, aube creates aube-lock.yaml. That is a new format, so a team adopting aube from scratch would be locked into aube's format. The README also mentions `aube update` to update dependencies within package.json ranges. The in-place lockfile behavior has a caveat: in daily mode, aube updates the lockfile as it installs. That means the lockfile can change under your feet. Only `aube ci` treats the lockfile as the source of truth, and it does so by deleting node_modules first. If you are used to npm's strict lockfile behavior in regular installs, aube's default is looser.

Node Version Management Built In

aube switches Node.js versions itself. If a project pins Node through package.json's `devEngines.runtime`, `.nvmrc`, or `.node-version`, every script and binary run through aube gets that version. This removes the need for a separate version manager like nvm or fnm. When a pinned version is missing, aube delegates the install to mise if you have it, sharing one Node store on disk. Otherwise it downloads from nodejs.org. Shell activation routes `node`, `npm`, `npx`, `pnpm`, `pnpx`, `yarn`, and `yarnpkg` through aube. The activation command is `eval "$(aube activate zsh)"` for zsh, or the bash and fish equivalents. This is a big integration point: if your team uses shell activation, then plain `node` commands also respect the project's pinned version. The README notes that package-manager shims route to aube commands, so the existing project lockfile kind stays authoritative. That means if you activate aube and run `pnpm`, it actually runs aube's resolver but writes to the same pnpm-lock.yaml.

Limitations and When aube Is the Wrong Tool

The most obvious limitation is the security friction. Lifecycle scripts waiting for approval will break builds that assume postinstall runs silently. If your project relies on packages with aggressive postinstall scripts, you will need to approve them, and the 24-hour cooling window for new releases could block a fresh dependency that was published minutes ago. The README does not explain how to configure the approval flow or the cooling window, so you would need to read the docs. Another limitation: the speed claims are benchmark ratios from the project's own site, not independent numbers. The README says warm installs are about 6x faster than pnpm and repeat test commands up to 21x faster, but those are aube's own benchmarks. You should measure on your own project. The `aube ci` command deletes node_modules before installing, which is fine for CI but destructive if you run it locally by mistake. Also, aube is a new project, v2.2.0 as of the last push, so the ecosystem of plugins and community knowledge is thin compared to pnpm or npm.

Alternatives: pnpm and Bun Take Different Routes

The closest alternatives are pnpm and Bun. pnpm is a mature package manager with a strict, content-addressable store and a strong focus on disk efficiency. aube also uses a global content-addressable store, so the disk-sharing idea is not new. The difference is aube's auto-install-on-script behavior and the security jail. pnpm does not auto-install before scripts; you run `pnpm install` explicitly. Bun is a runtime and package manager in one, written in Zig, and it is fast, but it does not have a lifecycle-script jail or the same security defaults. Bun also uses its own lockfile format, bun.lock, which aube can read, but Bun does not read aube-lock.yaml. If you want a proven, widely adopted tool with a huge ecosystem, pnpm is the safer choice. If you want speed and a bundled runtime, Bun is a contender. aube's edge is the combination of existing-lockfile compatibility and security defaults that neither pnpm nor Bun offers out of the box.

Maintenance and Upgrade Considerations

aube is a Rust binary distributed via mise, npm, and Homebrew. The npm package uses an install script to fetch native binaries, which means you need scripts enabled for that install path. The release notes for v2.2.0 mention a bundled compatibility catalog and an embeddable node-gyp bootstrap, which suggests the project is actively improving native module handling. v2.1.0 added faster script runs and echoed commands, and v2.0.1 introduced aube's own global home and lower install memory. The project is under active development, with the last push on 2026-08-25. The license is MIT, so you can adopt it without permissive-license concerns. The maintenance cost is learning a new set of commands: `aubr`, `aubx`, `aube ci`, `aube activate`. The README does not mention a migration tool for aube-lock.yaml back to other formats, so if you start a new project with aube-lock.yaml, you are invested. The docs at aube.jdx.dev are the place to check for breaking changes between versions, since the project is still iterating.

Editorial conclusion

Adopt aube if you manage many Node projects and want to stop running install before every script, or if you want stricter default security than pnpm or npm. Skip it if you need a package manager that treats the lockfile as sacred in daily workflows, because aube's default mode updates lockfiles in place and only `aube ci` enforces lockfile freshness. Before switching, verify that your team's lifecycle scripts, especially postinstall builds, pass the approval flow and that the 24-hour cooling window for new releases does not block your CI. Test `aube ci` in a staging pipeline first, because it deletes node_modules and re-installs from the lockfile, which is a behavior change from a plain install.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes