Bugs affecting complex pnpm workspaces

[stevelandeydescript]

I work in a monorepo that uses nearly every feature of pnpm and has a transitive dependency graph of 4,000+ packages. I kicked the tires on aube using coding agents because hey 3x would be a nice speedup. I made a lot of progress, but found some issues.

On the UX side: aube doesn't read things like patches and overrides from pnpm-workspace.yaml. I prefer to put them there rather than package.json so I can write long comments about why patches and overrides are needed. I can copy these things to package.json as a workaround, but I'd prefer not to.

On the correctness side, I have two apparent bugs which I will say up front I verified using agents and not my own brain. Caveat lector, slop ahead. Despite the LLM-generated nature of the bug reports, I did my best to create minimal repros here (using agents), visible in CI results: https://github.com/stevelandeydescript/aube-bug-repros

This is all on beta 9. Maybe that's out of date by now, with the pace you work at!

🤖 begin slop 🤖

1. npm: alias + override conflict. When a dependency uses an npm: alias (e.g. "immer": "npm:@descript/immer@6.0.9-patched.1"), aube incorrectly applies a version-range override meant for the unaliased package. The override immer@>=7.0.0 <9.0.6 should not match @descript/immer@6.0.9-patched.1 (different package, version outside range), but aube replaces the alias target with immer@11.1.4. pnpm handles this correctly. (CI run — aube jobs fail, pnpm jobs pass)

2. pnpm-lock.yaml only records host-platform optional deps. When aube generates or updates pnpm-lock.yaml, it only includes optional dependency entries for the current platform. pnpm includes all platforms. A lockfile generated on Linux is missing @esbuild/darwin-arm64, @oxlint/binding-darwin-arm64, etc., so macOS developers get "Cannot find native binding" errors. (CI run — aube's lockfile fails the darwin-arm64 assertion; the macOS install-from-Linux job fails at npx esbuild --version; pnpm comparison passes)

Repro repo with self-contained test cases for all three bugs: https://github.com/stevelandeydescript/aube-bug-repros

Bug 1 is the harder blocker — we use npm: aliases for patched forks of several packages. Bug 2 can be worked around by using pnpm to generate the lockfile and aube to install from it, but only if bug 1 is fixed (since the linker also ignores the alias).

🤖 end slop 🤖

[jdx]

Thanks for the detailed repros — the CI matrix against pnpm was really helpful. Opened #175 with fixes for all three:

1. npm alias + override conflict. range_could_satisfy couldn't parse the raw npm:@descript/immer@6.0.9-patched.1 as a semver, hit its "probably matches" fallback, and fired. The override matcher now sees just the trailing @<version> for npm: / jsr: aliases, so selectors whose version req doesn't cover the real version correctly stop firing.

2. pnpm-lock.yaml only records host-platform optionals. Extended the wide-platform resolver default (previously aube-lock.yaml only) to pnpm-lock.yaml writes, so teammates on other platforms install from a Linux-generated lockfile without "Cannot find native binding". Install-time filter_graph still trims node_modules to the host.

3. pnpm-workspace.yaml overrides + patches. Your diagnosis was exactly right — the resolver already merged workspace overrides, but the drift check only read package.json. Threaded workspace overrides through check_drift / check_drift_workspace. Also added patchedDependencies support in pnpm-workspace.yaml alongside package.json (workspace wins on key conflict, matching pnpm v10).

Manually verified each fix against your repro dirs; all three install correctly now. Should land on the next beta.

Written with Claude.

[stevelandeydescript]

Nice! Maybe a wider pnpm-workspace.yaml compatibility pass would be good if you haven't done one already. There's more stuff in there that might be missed. I'll do another pass when the next release is out and get back to you.

[stevelandeydescript]

I found one more thing I'd consider a bug, and a blocker from migrating from pnpm to aube. Documented at the same URL, with a new set of CI checks. https://github.com/stevelandeydescript/aube-bug-repros

In a multi-package monorepo with a root package.json file, pnpm will hoist dependencies from root package.json regardless of the other hoisting settings.

There are other resolution differences from pnpm, but nothing I'd consider a "bug" per se.

[jdx]

Reproduced this one from your repro repo and opened a fix in #199: #199

Root cause: aube install --filter ... was trimming the importer set down to only the selected workspace packages, which dropped the root importer (.) entirely. That meant root package.json deps/devDeps never got linked during filtered installs.

The fix is to always keep the root importer when a workspace filter is active, then prune everything else from the selected workspace set as before. With that change, your repro now behaves like pnpm:

aube install --filter @repro/app...
node test.js
# OK: esbuild-register is resolvable from root

I also added a regression test covering aube install --filter with a root devDependency, so this specific behavior stays locked in. This should be in the next beta.

[jdx]

I work in a monorepo that uses nearly every feature of pnpm and has a transitive dependency graph of 4,000+ packages.

btw, was very happy to see this! seems like we're getting there and this is a great stress test for parity

also, once we get it working we should look at perf—we've been identifying perf issues with certain projects for sure. If nothing else I'll be curious how it compares.

[stevelandeydescript]

One more bug:

--frozen-lockfile rejects catalog: references in overrides. pnpm resolves catalog: to the catalog value before comparing against the lockfile. aube compares the raw catalog: string, so it always reports a mismatch. Workaround: replace catalog: in overrides with literal values.

Repro in the usual place.

With a workaround for that (just don't use catalog: in overrides), aube is about 30% slower than pnpm for us. Let me know if there's a profiling process I can run to help you understand why.

[jdx]

Got this one too — #249.

Actually two bugs stacked behind your symptom:

1. Override-map drift. check_drift was comparing the raw catalog: string from pnpm-workspace.yaml against the catalog-resolved value pnpm writes into the lockfile (4.17.21). Fixed by threading workspace_catalogs through the drift check and resolving catalog: / catalog:<name> on both sides before comparing.

2. Importer-spec drift. Once (1) was fixed, the next error surfaced: pnpm rewrites the importer specifier: to the post-override value when a bare-name override fires, so pnpm-lock.yaml records specifier: 4.17.21 while package.json still reads ^4.17.0. This was a pre-existing bug your repro happened to mask. check_drift_for_importer now accepts the effective override spec as a fresh match, which also makes plain non-catalog pnpm overrides work on frozen installs.

Verified against your frozen-lockfile-catalog-override repro end-to-end and added four regression tests in aube-lockfile. Should ship on the next beta.

On the 30% perf gap — yes, please do send a profile when you can. The cleanest thing would be a samply profile of aube install on a warm store with --frozen-lockfile (so the resolver is skipped and we're timing fetch + link + script passes). Run:

cargo install samply
samply record -- aube install --frozen-lockfile

and attach the profile.json. A hyperfine comparison (hyperfine -w 1 'aube install --frozen-lockfile' 'pnpm install --frozen-lockfile') against the same repo also helps triangulate. If the gap is in resolution (cold lockfile), a profile of the non-frozen path would be more useful.

Written with Claude.