Fixed!

Thanks for the report — pushed #346 which addresses both halves:

• The strict-equality check inside git_shallow_clone was already loosened in #339 to accept a prefix match, so a lockfile that records a short SHA no longer trips the post-checkout verification.
• Case 2 (abbreviated SHA written directly in package.json) was rejected upfront by git_resolve_ref because ls-remote doesn't advertise non-tip commits. fix(resolver): accept abbreviated git commit SHAs in user specs #346 lets the prefix flow through and recovers the full 40-char SHA from the post-checkout rev-parse HEAD so the lockfile always pins the canonical form, regardless of what the user wrote.

Smoke-tested on github:collinstevens/vfs#0b6ea53 — installs cleanly and the lockfile pins 0b6ea539609031977983f0b2393ebe81ee28c8ec.

Written with Claude.

Fixed in #355.

Root cause was the Bun lockfile importer storing full name@version strings inside LockedPackage.dependencies, while the linker expects dependency values to be dep-path tails. That produced broken nested sibling links such as node-gyp-build@node-gyp-build@4.8.4, so dep lifecycle scripts could not resolve their own deps/bins after importing from bun.lock.

I reproduced your exact bufferutil / electron / fs-extra sequence and verified aube install --no-side-effects-cache now exits cleanly.

Thanks for the report. Opened #356.

I checked the linked job: it is running aube 1.2.1 and stalls during a tarball fetch before surfacing HTTP error: error decoding response body for @sourcemeta/jsonschema. Current main already has better tarball body retry behavior and visible retry warnings after #331, but #356 adds a narrower hardening: tarball downloads now send Accept-Encoding: identity because npm tarballs are already .tgz files and an extra HTTP content-encoding layer only adds another decode failure mode.

Validation: cargo test -p aube-registry retry_tests and cargo test -p aube-registry.

Thanks, I looked at this next. The @babel/helper-string-parser@7.27.1 tarball and integrity from npm are valid, so the empty package.json parse error points at a stale/truncated content-addressed file already present in the local aube store.

Before a patched aube release is available, the workaround is to clear the local aube content store and rerun the install:

rm -rf "${XDG_DATA_HOME:-$HOME/.local/share}/aube/store/v1/files"
aube ci

That removes cached package contents only; the next install will download them again. If XDG_DATA_HOME is customized in CI, use that value instead of the default ~/.local/share path.

I opened #357 to repair that path: fresh imports now verify an existing CAS file has the expected byte length, rewrite it if it is truncated, and include a regression test for the zero-byte manifest case.

thanks! I tried aube store prune and could install. Now aubr build:all fails because it cannot find 'rxjs'

✖ Compiling with Angular sources in partial compilation mode.
../../../../.cache/aube/virtual-store/@ngx-translate+core@16.0.4_@angular+common@21.0.8_@angular+core@21.0.8_@angular+compile_22b186c80767c364ba71d95e2363ab6b/node_modules/@ngx-translate/core/lib/missing-translation-handler.d.ts:1:28 - error TS2307: Cannot find module 'rxjs' or its corresponding type declarations.

1 import { Observable } from "rxjs";
                             ~~~~~~
../../../../.cache/aube/virtual-store/@ngx-translate+core@16.0.4_@angular+common@21.0.8_@angular+core@21.0.8_@angular+compile_22b186c80767c364ba71d95e2363ab6b/node_modules/@ngx-translate/core/lib/translate.loader.d.ts:1:28 - error TS2307: Cannot find module 'rxjs' or its corresponding type declarations.

@dr-itz thanks, tracked the rxjs follow-up down. This is a GVS + hidden-hoist interaction, not an rxjs package-specific problem.

@ngx-translate/core imports rxjs from its .d.ts files but does not declare it as a dependency/peer. That normally works through hoisting, but with the global virtual store the compiler is resolving from the real ~/.cache/aube/virtual-store/... path, so it cannot see the project-local hidden hoist.

I opened #358 to fix that by mirroring the hidden-hoist links into the shared global virtual-store root as well. I also updated the PR after review so the shared GVS hoist is populated additively rather than wiping the shared directory on each install.

Until that lands in a release, disable GVS for this project and reinstall:

aube config set enableGlobalVirtualStore false --location project
rm -rf node_modules
aube ci

Equivalent one-shot install workaround:

aube ci --disable-global-virtual-store

If .npmrc is easier in CI, this is the same project-level setting:

enableGlobalVirtualStore=false

Awesome, thanks, that works fine now with 1.4.0

Thanks, dug in next. Tracked it to the npm-lockfile parser, not the linker.

package-lock.json records every workspace member as a top-level node_modules/<name>: { link: true, resolved: "<rel>" } entry independent of the root package.json — npm symlinks them all into the workspace root regardless of whether they appear in dependencies / devDependencies. Aube was seeding the root importer's direct deps only from those three manifest fields, so the 11 projects/* workspaces in siemens/element never reached the linker as root deps and node_modules/@siemens/element-ng (and the other 10) silently went missing — exactly what you saw, and why aubr build:all could not resolve them.

#374 surfaces every top-level link entry from the lockfile (plain or scoped, no nested node_modules/ segment) as a direct dep of the root importer when the npm parser builds the graph. Explicit dependencies: { "@scope/x": "file:packages/x" } declarations dedupe through the existing path so they do not double up.

Reproduced your shape locally — root manifest declaring workspaces: ["projects/foo", "projects/bar"] with neither workspace in root dependencies and a matching package-lock.json. Before: node_modules/@scope/ empty after aube install. After: both @scope/foo and @scope/bar symlinks present pointing at ../../projects/<name>, registry deps still resolved correctly.

You should not need to set hoist-workspace-packages once this lands — the missing root links were the actual bug, not that setting.

Written with Claude.

Thanks for the clear repro. I opened #386 for this.

Root cause was that the tarball path validator rejected : on every platform as part of the Windows path-safety checks. That was too broad: : is a valid POSIX filename character, and the reported redos-detector path should install on Linux/macOS. The linker has a second defensive index-key validator, so #386 applies the same platform split there too: POSIX accepts colon filenames, Windows still rejects them because of NTFS alternate data streams/path creation rules.

Validation:

cargo fmt --check
cargo test -p aube-store
cargo test -p aube-linker
cargo clippy -p aube-store --all-targets -- -D warnings
cargo clippy -p aube-linker --all-targets -- -D warnings

I also ran your redos-detector@6.1.4 repro against the debug binary and aube install now completes.

This comment was generated by Codex.

I would probably post a comment upstream to the package maintainer though since it won't work on windows with any package manager unless I'm missing something

Good call I'll open a issue. It is working on a Windows machine with npm, so I'm unsure

Thanks for the repro. Opened #403.

Same shape as the catalog fix in #384, just at a different layer. pnpm encodes aliased transitive deps as <alias>: <real>@<resolved> inside a snapshot's dependencies: block (e.g. @isaacs/cliui@8.0.2 records string-width-cjs: string-width@4.2.3), and the reader was passing that value through unchanged. The linker then keyed the sibling symlink against <dep_name>@<dep_value> and produced a broken string-width-cjs@string-width@4.2.3 virtual-store path; on a re-resolve the lockfile-reuse path enqueued a transitive with range = string-width@4.2.3, which is what surfaced as the no version of string-width-cjs matches range error in your report.

The PR detects the alias shape at parse, rewrites the dep value to the bare resolved version (peer-context suffix preserved), and feeds the existing alias_remaps channel — same hook the importer-level path uses — so a synthetic string-width-cjs@4.2.3 LockedPackage with alias_of=Some("string-width") gets created. After that the linker symlinks correctly and the resolver's reuse path matches it by name+version without seeing the malformed range.

Verified against your repro: pnpm install → rm pnpm-lock.yaml node_modules → aube install succeeds, and node -e "require('jackspeak')" from packages/app/ loads without surfacing the broken string-width-cjs link.

Written with Claude.

Thanks for the repro. Opened #489.

Root cause is the Bun parser path for workspace direct deps. Bun scopes this lockfile entry by workspace package name (z-app/tslib), while aube was only checking the workspace directory path (packages/z-app/tslib) before falling back to the hoisted bare tslib entry. That made packages/z-app link tslib@2.8.1 instead of its own locked tslib@2.4.0.

#489 makes workspace importers prefer <workspace package name>/<dep> before the existing path-scoped and hoisted fallbacks, and keeps the prior guard that avoids treating intermediate workspace directory segments as package nesting.

Validation:

cargo fmt --check
cargo test -p aube-lockfile workspace_dep
cargo test -p aube-lockfile test_parse_workspace_path_does_not_alias_npm_package
cargo clippy -p aube-lockfile --all-targets -- -D warnings
cargo build

I also ran your repro against the debug binary and confirmed packages/z-app/node_modules/tslib now links to ../../../node_modules/.aube/tslib@2.4.0/node_modules/tslib.

This comment was generated by Codex.

Thanks, agreed that the Bun-style precedence is more intuitive here. I opened #502.

The PR keeps scripts first, then falls aube run <name> back to a matching local node_modules/.bin/<name> when no script exists. It also makes aube dlx / aubx prefer an installed local binary unless -p / --package is provided, in which case it still does the explicit throwaway install. I updated the README, package-manager docs, and CLI reference text so this precedence is visible.

Validation: cargo fmt --check, cargo test -p aube dlx, cargo test -p aube allow_build_review_tests, mise run test:bats test/run.bats, mise run test:bats test/dlx.bats, and cargo clippy -p aube --all-targets -- -D warnings.

This comment was generated by Codex.

could probably add this, might be worth taking a look to see what else should be passed to node

Thanks for adding this feature (I have noticed it in v1.9.0 release notes). All works as expect.

I don't think my yaml parser—or any yaml parser in rust is able to deal with comment retention. I might need to create my own yaml parser 😞. I will if I have to though, this definitely needs to be fixed.

I was wrong, there is this https://crates.io/crates/yamlpatch

This looks like a simple-git-hooks bug. aube sets INIT_CWD to the project root (npm/pnpm/yarn convention for exactly this case), but simple-git-hooks ignores it and instead pattern-matches .pnpm in process.cwd() to find the consumer's package.json. It doesn't know about .aube, so it lands on the wrong path. Fix belongs upstream.

This comment was generated by Claude.

not too familiar with that project but from a quick glance it seems like git sherlocked it with the last release and their global hook feature. I'd probably just use that instead.

Thanks, I tracked this to the frozen drift check after import. aube import preserves npm workspace root links in aube-lock.yaml, but aube ci was then treating those root link: entries as removed manifest dependencies when the root package.json does not declare them. That prevented the linker from recreating the node_modules/@siemens/* workspace symlinks after switching from package-lock.json to the aube lockfile.

I opened #535 to keep root link: entries that point at current workspace packages during workspace-aware frozen drift checks. I also verified a minimal aube import && rm package-lock.json && aube ci --ignore-scripts repro now recreates the root workspace symlinks.

This comment was generated by Codex.