GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #1276

Summary

Hosted Bun unwinds (rollback, remove <purl>, and the hosted → vendored takeover for bun.lock and bun.lockb) now look up each package's registry the way Bun does. That includes the user's .npmrc and the global bunfig, not only the files beside the lock.

Before this, a private scope set only in ~/.npmrc or ~/.bunfig.toml (the usual place, since tokens aren't committed) was looked up on the public registry, without credentials, which also leaked the private package name. The restore then either failed with a 404 or exited 0 after writing "" plus a same-name public package's integrity. That lock breaks cold frozen installs on Bun ≥ 1.3.7 and installs the public package on Bun ≤ 1.3.6.

Root cause

BunRegistrySettings::read (crates/socket-patch-core/src/patch/redirect/upstream/npm.rs) read only {lockdir}/.npmrc and {lockdir}/bunfig.toml. It modelled one project-level config, not Bun's layered one.

Measured Bun behaviour

Measured with a request-logging mock registry on Bun 1.1.39, 1.2.23, 1.3.6, 1.3.7, 1.3.9, 1.3.12, 1.4.0 and 1.4.2 (Linux). Every layer below was varied pairwise.

• User .npmrc: $XDG_CONFIG_HOME/.npmrc when that file exists, else ~/.npmrc. NPM_CONFIG_USERCONFIG is ignored.
• Global bunfig: $XDG_CONFIG_HOME/.bunfig.toml when XDG_CONFIG_HOME is set (Bun then never reads ~/.bunfig.toml), else ~/.bunfig.toml.
• Merging: settings merge per key. A key in a project file beats the same key in the user or global file of the same kind, and unrelated keys still come from the user or global file. A scope entry beats any default registry. The env registry beats the configured default registry but not a scope.
• Precedence flip in Bun 1.4.0: Bun ≤ 1.3.x takes any .npmrc key over any bunfig key. Bun ≥ 1.4.0 does the reverse.
• Lock versions: Bun 1.4 is the first to write lockfileVersion: 2, and Bun 1.3 ignores a v2 lock. Bun 1.4 keeps a v1 lock as v1, so a v0/v1 lock (or a bun.lockb) doesn't say which Bun installs it.

The fix

• BunConfigFiles holds the .npmrc layers (project, then user) and the bunfig layers (project, then global). bun_user_config_paths finds the user files as measured above. bun_lookup_layered resolves each key from the highest-precedence file that sets it, in either kind order.
• BunConfigOrder:
  • A v2 bun.lock uses bunfig-first (Bun ≥ 1.4).
  • A v0/v1 bun.lock or a bun.lockb is Unknown. A package is refused, with the existing checkout remedy, only when the two orders give a different registry or credentials. Otherwise the restore proceeds as before.
• Variable expansion: the user's own files expand any ${VAR}, as Bun does (e.g. //npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}). Project files keep the existing NPM_TOKEN / NODE_AUTH_TOKEN / BUN_AUTH_TOKEN allowlist. Credentials are never printed: refusals show only bases, which have their userinfo stripped.
• Both callers (restore_bun_locks, and the bun.lockb takeover restore) go through refuse_ambiguous before fetching.
• CLI_CONTRACT.md and docs/ecosystems.md describe the layering, the version split and the refusal.

Behaviour change for maintainers: a project whose own .npmrc and bunfig.toml name different registries for the same package, on a v0/v1 bun.lock, used to be restored npmrc-first. It is now refused with the checkout remedy, because Bun 1.4 would resolve it bunfig-first. On a v2 lock it now follows Bun 1.4 (bunfig-first) instead of npmrc-first. The flip is real but small in practice: it only matters when both kinds set the same key differently.

Also included: one rustfmt-only line in upstream/mod.rs. Main isn't cargo fmt --check clean on it, and the cargo fmt --all step required before marking ready reformatted it.

Tests (red → green)

The integration tests are in crates/socket-patch-cli/tests/in_process_vendor_bun_takeover/registry.rs. Core unit tests in npm.rs:

• bun_user_config_paths_follow_bun_s_lookup
• bun_layers_take_each_key_from_the_highest_file_that_sets_it
• bun_user_files_expand_any_variable_project_files_only_token_ones
• bun_refuses_a_registry_the_lock_s_bun_version_would_decide

The existing #992 tests still pass unchanged.

in_process_vendor_bun_takeover's runner now also removes XDG_CONFIG_HOME, so a developer's user config can't steer the fixtures. HOME was already pinned to a stand-in.

Commands run locally

• cargo fmt --all -- --check: ok.
• cargo clippy --locked --workspace --all-features -- -D warnings: ok. --all-targets reports nothing in the changed files; its other findings are in files this PR doesn't touch.
• cargo test -p socket-patch-cli --all-features --test in_process_vendor_bun_takeover: 40/40.
• cargo test -p socket-patch-core --lib redirect::upstream: 119/119.
• SOCKET_PATCH_BUN_E2E_REQUIRED=1 SOCKET_PATCH_BUN_E2E_VERSION=1.4.2 cargo test -p socket-patch-cli --all-features --test e2e_redirect_bun_build -- --include-ignored: 36/36. The 1.1.45 / 1.2.23 / 1.3.14 legs run in CI.
• cargo test --workspace --all-features --no-fail-fast: 13 failures, all environmental and none in Bun or redirect code:
  • 12 are permission-based write-failure tests (covgap_commands_vendor, repair, copy_tree, vlt_heal, vendor::pypi_*, in_process_redirect write-failure cases). The sandbox runs as uid 0, which ignores chmod 0o555.
  • 1 is mode_migration_pypi::pipenv_hosted_to_vendored…, which fails fetching https://pypi.org through the sandbox's TLS-inspecting proxy (the Every HTTPS call fails behind a TLS-inspecting proxy because the clients trust only bundled webpki roots #1107 shape).
• Wrappers under npm/, pypi/ and gem/ only dispatch to the binary, so they need no change.

Follow-ups (not in this PR)

• Hosted yarn berry rollback/remove still drops a mirror's ::__archiveUrl= binding when the registry comes from npmScopes, YARN_NPM_REGISTRY_SERVER, ~/.yarnrc.yml or a parent-dir .yarnrc.yml (#908 fix covers only the project rc's top-level key) #1017 is the yarn berry twin (berry_lookup_registry ignores ~/.yarnrc.yml, npmScopes registries and YARN_NPM_REGISTRY_SERVER). It's a separate reader, so it's left for its own PR.

🤖 Generated with Claude Code

Generated by Claude Code