[robobun]

Problem

• A package that bun install extracts from the cache (registry, git, remote tarball) can declare "other": "file:./other.tgz", file:../x.tgz or an absolute path. bun reads that path relative to the project, without looking at who declared it. A published package gets whatever .tgz the project holds at that path installed under a name of its choosing: bun.lock records "other": ["evil-other@./other.tgz", ...]. Found by inspection, not from a report.
• Cause: local_tarball_base_dir (src/install/PackageManager/PackageManagerEnqueue.rs) knows a workspace or file: folder declarer. Every other declarer falls through to the project directory. That also reads a local tarball's own file: tarballs from the project, where npm reads them from next to the tarball (arborist from-path.js).

Fix

• The Tarball arm refuses a local tarball edge unless the project stands behind it: the declarer is read from the project (Lockfile::is_dependency_of_local_package, the folder guard's predicate), the specifier came from the root package.json (version_was_replaced), the root declares the same dependency (has_equal_root_dependency), the declarer is a local tarball, or the edge belongs to no package (auto-install). Optional edges are skipped. Required ones, peers included, fail with an error that names the declarer and the remedy. Nothing is written.
• locate_next_to_declaring_tarball resolves a file: tarball declared by a local tarball against the directory that tarball was read from, and stores that location (posix, ./-prefixed, from the top-level dir) as the resolution. So vendor/a.tgz -> file:./b.tgz -> file:./c.tgz installs from vendor/ as with npm, the lockfile row names the file, two tarballs that each declare ./x.tgz get their own, and --frozen-lockfile and bun update read the same file.
• Verified: test/cli/install/bun-install.test.ts, block "file: tarballs declared by a package installed from the cache" (16 tests, 10 fail on the released build). Also the tarball, file: and folder tests of bun-install, bun-workspaces, overrides, bun-add, isolated-install, and cargo clippy -p bun_install.

Background

• A file: .tgz dependency is a Tag::Tarball edge with a local URI. It resolves to Resolution::LocalTarball(<path as written>), and that path string is the package identity in bun.lock.
• bun reads the package.json of the root, workspaces, file: folders and local tarballs from disk. Every other package comes from the cache and is not on disk when its edges resolve, so no file: path it writes can mean what it says. Refusing is the only consistent answer, and npm 12's allow-file=root does the same.
• Considered leaving local tarball declarers on the project directory, as on main. That refuses a layout npm installs. Reading next to the tarball matches npm and fixes the vendor/ layout, which fails with ENOENT on main.

Downsides

• A project whose cache dependency declares a file: tarball kept at the project-relative path installed before and now exits 1 with the remedy in the error. No other package manager installs that shape.
• A local tarball in a subdirectory that declares file:./x.tgz for an x.tgz in the project root installed before and now fails with ENOENT, as with npm. Per edge declared by a local tarball the cost is one scan of the dependency list and one string appended to the lockfile. Registry edges pay nothing: the guard sits behind Uri::Local.

Notes

• Split out: install: fail --lockfile-only on an error logged while resolving #44364 makes --lockfile-only fail on an error logged while resolving. Without it, the peer case here prints the refusal, saves bun.lock and exits 0 under --lockfile-only, as every resolve error did on main.
• Same class, other PRs: link: paths declared by a cache package (install: refuse link: targets that leave the project when a package from the cache declares them, at resolve and install time #39023, which should use the same predicate as this guard), a file: folder's own tarballs read relative to the folder (install: read the package.json of a file: dependency declared by a local file: package #38814). Not covered: git+file:///abs/repo declared by a cache package, and bun -i taking a file: spec from a package.json under node_modules and handing it to enqueue_dependency_to_root as a parentless edge. Both are entry points of their own.
• Overrides only reach an edge whose declared specifier is a range: bun looks overrides up by realname(), which is empty for tarball and git specifiers. Separate bug. The root-declared remedy does not depend on it.
• The task key and the package identity of a local tarball are its path string. A root ./x.tgz and a workspace ./x.tgz share one extraction on main and still do. A tarball declared by a local tarball is stored by its location, so it does not collide.
• The earlier account (npm and pnpm both resolve relative to the declaring package, which is not on disk) was wrong for tarball declarers: npm resolves a local tarball's file: edges against dirname(tarball). The text above is corrected.
• has_equal_root_dependency stays root-only: a workspace's file:./x.tgz is relative to the workspace, a cache package's equal edge to the project, so they do not name the same file.
• A bundled edge gets the error without the root remedy: the root cannot stand in for a dependency that ships inside the declaring package.
• Self-reviewed: 7 concerns raised, 5 addressed (predicate shared with the folder guard, --lockfile-only exit code moved to install: fail --lockfile-only on an error logged while resolving #44364, local tarball declarers read next to the tarball, bundled edges get no root remedy, PR body corrected). Rejected: accepting a workspace's equal edge (different base directory) and treating re-resolved lockfile rows differently (they go through the same decision as a fresh edge).

---

no test proof · iteration 2 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/cli/install/bun-install.test.ts

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

The installer checks root declarations when remote packages specify local tarball dependencies. It rejects required dependencies without an equal root declaration and skips optional dependencies. Lockfile handling now resets load errors after optional reporting and checks for prior errors before a lockfile-only save.

Changes

Local tarball dependency validation

Layer / File(s)	Summary
Root dependency checks src/install/lockfile.rs	The lockfile compares dependencies with root declarations to find an equal dependency name and specifier.
Enqueue and install validation src/install/PackageManager/PackageManagerEnqueue.rs, src/install/PackageManager/install_with_manager.rs	The enqueue path rejects required local tarball dependencies from remote packages when no equal root dependency exists, and skips optional dependencies. The lockfile-only path checks for prior errors before saving.
CLI install coverage test/cli/install/bun-install.test.ts	Tests cover rejected declarations, matching root dependencies, overrides and resolutions, optional dependencies, and local folder packages.

Lockfile error handling

Layer / File(s)	Summary
Lockfile error recovery src/install/PackageManager/install_with_manager.rs, test/cli/install/bun-lock.test.ts	The installer resets lockfile load errors after the optional reporting block. Tests verify that silent installs replace malformed lockfiles successfully, with and without --lockfile-only.

Suggested reviewers: alii

Priority: ➖ Normal

Merge Risk: 🔵 Low · up to 68ad1

A silent install can succeed despite an invalid HTTP-request configuration setting, and lockfile-only mode may write a lockfile. Preserve the earlier configuration error; the remaining local-tarball behavior follows the repository’s direct-declaration restriction.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: refusing local tarball dependencies declared by cached packages.
Description check	✅ Passed	The description explains the problem, fix, scope, behavior, downsides, and verification results. It does not use the exact template headings, but it provides the required information in equivalent sec…

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: reproduced on the released build (1.4.0 canary) with a tarball, a git and a registry declarer, each declaring file:./inside.tgz, file:../outside.tgz and an absolute .tgz path, as dependencies, peerDependencies and optionalDependencies: the planted tarballs were installed from outside the declaring package, exit 0, rows written to bun.lock. With this branch each such edge is refused while resolving unless the project stands behind it (declared by a project manifest, substituted by root overrides/resolutions, or declared identically by the root package.json, which the error now points to); exact output is pinned by the 11 tests in test/cli/install/bun-install.test.ts. Rebased onto main so CI no longer hits the stream use-after-free that was failing the x64-asan lane on earlier runs.

[claude]

I reviewed this PR and didn't find any bugs. Because it changes install-time resolution behavior on a security-relevant path (blocking local tarball reads triggered by remote packages) and encodes a design decision about where the local/remote boundary sits, a human look would still be worthwhile.

What was reviewed:

• The new guard in the Tarball arm of enqueue_dependency_with_main_and_success_fn — fires only for Uri::Local, only when the specifier was not substituted by root overrides/resolutions/catalogs, and only when a declaring package exists and is not Root/Workspace/Folder; auto-install edges (no declarer) are unaffected.
• The two Root | Workspace | Folder → is_local_package() refactors in verify_resolutions and is_filtered_dependency_or_workspace — semantically identical to the originals.
• get_parent_pkg_of_dependency — same scan shape as the existing get_workspace_pkg_if_workspace_dep, only reached for local-tarball edges.
• Test coverage — tarball/git/registry declarers each with in-project, ../, and absolute paths; optional-dep silent skip; overrides/resolutions exemption; file: folder declarer still allowed.

Extended reasoning...

Overview

This PR closes a hole where a package installed from the cache (registry, git, or tarball) could declare a file:./x.tgz dependency and have bun read that path relative to the project directory — so a published package could pull in whatever .tgz happened to sit in (or above, or at any absolute path on) the installing machine. The fix adds a guard in the Tarball arm of enqueue_dependency_with_main_and_success_fn (PackageManagerEnqueue.rs) that refuses local-tarball edges whose declaring package is not itself read from the project. It also introduces resolution::Tag::is_local_package() to name the Root/Workspace/Folder set once and rewires the two existing hand-written matches (Tree.rs, verify_resolutions) to it, adds Lockfile::get_parent_pkg_of_dependency, a #[cold] error emitter, and ~200 lines of tests in bun-install.test.ts.

Security risks

The change reduces attack surface — it stops remote packages from reading arbitrary local tarballs into node_modules under a name of their choosing. The exemptions are the right ones: version_was_replaced (the specifier came from the root's own overrides/resolutions/catalogs, so it is project-authored), and edges with no declaring package (auto-install). The install-from-lockfile path is deliberately left alone, which means an older bun's bun.lock row keeps installing — that is a considered trade-off the description spells out, and I think it's the right call, but it's exactly the kind of boundary a maintainer should sign off on. The analogous link: (Symlink) hole is called out as tracked separately.

Level of scrutiny

High. This is core bun install resolution, it changes user-facing behavior (installs that previously "succeeded" now exit 1), and it draws a security boundary. The PR description is unusually thorough about the mechanism, the alternatives considered (reject vs. read from the declarer's extracted tree), and what was deliberately left out of scope — all of which reads correctly to me — but those are design calls that belong with a human reviewer.

Other factors

The two is_local_package() refactors are byte-for-byte semantic no-ops. get_parent_pkg_of_dependency is an O(packages) scan per local-tarball edge, which is fine given how rare that edge type is and matches the existing get_workspace_pkg_if_workspace_dep pattern right below it. is_required() is !is_optional(), so a non-optional peer local-tarball from a remote package will get the "refusing to resolve" error added to the log even though verify_resolutions skips peers — probably desirable, but worth a glance. Test coverage is comprehensive: every remote declarer kind × every path shape, plus the optional, overrides/resolutions, and file: folder boundary cases; the tests use a local dummy registry and a locally-served git repo, no external network.

[robobun]

On the peer dependency point: a non-optional peer declared as a local tarball by a package from the cache already fails the install today (the tarball read fails with ENOENT extracting tarball from <name>, which is logged as an error), and the directory form does the same through the MissingPackageJSON branch, which also only checks is_required(). So keeping peers on the error path preserves the current outcome for them and only changes the message; the optional case is the one whose outcome changes (skipped instead of failing), and that is covered by a test.

[robobun]

^{Updated 4:05 PM PT - Oct 1st, 2026}

✅ @robobun, your commit 20f1224cca1da2a80d6394987a09e08669ebe4bd passed in Build #122566! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 38986

That installs a local version of the PR into your bun-38986 executable, so you can run:

bun-38986 --bun

[claude]

I reviewed this PR and didn't find any bugs. Because it adds a security boundary to package resolution with several deliberate exemptions (overrides/resolutions, auto-install edges, optional vs. required vs. peer handling, the install-from-lockfile path left as-is), a human look would still be worthwhile.

What was reviewed:

• The new guard in the Tarball arm — placement before dedupe/task-queue matching, the version_was_replaced and is_required() gates, and that get_parent_pkg_of_dependency returning None (auto-install edges) falls through unchanged.
• is_local_package() matches the two existing Root | Workspace | Folder sites it replaces exactly; no other resolution tag reads its package.json from the project.
• Test block covers tarball/git/registry declarers × relative/../absolute paths, plus peer, optional, overrides/resolutions, and file: folder — the boundary tests pass before and after, the refusal tests fail on the released build.
• The unrelated CI failure (spawn-stdin-readable-stream.test.ts ASAN) does not touch install.

Extended reasoning...

Overview

This PR closes a supply-chain hole in bun install: a package installed from the cache (registry, git, or tarball) that declares a local file: tarball dependency previously had that path read relative to the installing project's directory, so a published package could pull in whatever .tgz happened to sit at that path on the user's machine (including ../ and absolute paths). The fix adds a guard in the Tarball arm of enqueue_dependency_with_main_and_success_fn that refuses local-tarball edges whose declaring package is not itself read from the project (root, workspace, or file: folder). It also introduces resolution::Tag::is_local_package() and refactors the two existing hand-written Root | Workspace | Folder matches (Tree.rs, verify_resolutions) to use it, and adds Lockfile::get_parent_pkg_of_dependency — the same linear scan get_workspace_pkg_if_workspace_dep already does, minus the tag filter. ~230 lines of new tests cover the matrix.

Security risks

This is the security-sensitive part. The change tightens behavior (refuses reads that were previously allowed), so the risk is not that it opens a hole but that an exemption is too broad or a path is missed. The exemptions I checked: version_was_replaced (overrides/resolutions/catalogs come from the root package.json, so reading relative to the project is what the user wrote); get_parent_pkg_of_dependency returning None (auto-install edges appended by enqueue_dependency_to_root, which come from the CLI, not a remote package); and the install-from-lockfile path (enqueue_tarball_for_reading) deliberately left alone so lockfiles written by an older bun keep installing. The PR body also names two adjacent holes deliberately left for follow-up (link: from a cached package, and file: folder tarballs read relative to the project rather than the folder). None of the exemptions look wrong to me, but they are policy choices worth a maintainer's confirmation.

Level of scrutiny

High. This is the package manager's dependency-resolution path and the change decides which filesystem paths a remote package is allowed to cause bun to read. The guard sits in a hot function (enqueue_dependency_with_main_and_success_fn), though the new linear scan only fires for local-tarball edges, which are rare. The is_required() gate means required and non-optional-peer edges error while optional ones silently stay unresolved — the PR body argues this matches how the directory form's MissingPackageJSON branch behaves, and the tests pin both outcomes.

Other factors

The refactor of the two existing match arms into is_local_package() is behavior-preserving (same three tags, same else branch). The new helper on Lockfile uses the same .contains() idiom as its neighbor. The comment-cop bot flagged long doc comments in an earlier revision; those were trimmed in db9d41d and the threads are resolved. The one CI failure so far is an ASAN failure in spawn-stdin-readable-stream.test.ts, which is unrelated to install code. Test coverage is thorough (three declarer kinds × three path shapes, peer/optional variants, override/resolutions exemption, folder-declarer allowed) and the tests are hermetic (local dummy registry, local git over HTTP, temp dirs). Given the security-sensitive surface and the several policy decisions embedded in the guard, I'm deferring rather than approving.

[claude]

I reviewed this PR and the automated bug hunt found no issues. Because it changes security-sensitive package-manager resolution behavior — deciding which declarers may read local tarballs, plus the new has_equal_root_dependency escape hatch and the peer/optional split — a human look would still be worthwhile.

What was reviewed:

• The new guard in the Tarball arm of enqueue_dependency_with_main_and_success_fn and its interaction with version_was_replaced, get_parent_pkg_of_dependency (auto-install edges return None), and has_equal_root_dependency.
• The is_local_package() refactor in Tree.rs / verify_resolutions — same three tags as the matches it replaces.
• Optional-peer edges reaching the error path (raised and ruled out: they already failed with ENOENT before, so behavior is preserved).

Extended reasoning...

Overview

The PR closes a hole where a package installed from the cache (registry, git, or tarball) could declare "x": "file:./x.tgz" / file:../x.tgz / an absolute .tgz path and have bun read that tarball from the project directory (or anywhere on disk) rather than from inside the declaring package. The fix adds a guard in the Tarball arm of enqueue_dependency_with_main_and_success_fn that refuses local-tarball edges whose declaring package is not Root | Workspace | Folder, unless the specifier came from a root override/resolution (version_was_replaced) or the root package.json declares an identical edge (has_equal_root_dependency). It also introduces resolution::Tag::is_local_package() and rewires the two existing hand-written Root | Workspace | Folder matches through it, and adds ~300 lines of tests covering tarball/git/registry declarers × relative/..//absolute paths, peer/optional variants, overrides/resolutions, the root-declares-it-too escape hatch, and file: folder declarers.

Security risks

This is the security-sensitive change: it defines which package.json files are trusted to reference filesystem tarballs during bun install. The fix tightens behavior (fail-closed on remote declarers), and the escape hatches are project-controlled (root overrides/resolutions and an identical root dependency). I did not find a way for a remote package to influence version_was_replaced or the root-dependency comparison, and Dependency::eql compares both name and literal so a remote package cannot piggy-back on a differently-named or differently-pathed root tarball (covered by the two negative "still rejects" tests). But because this is a trust boundary in the package manager, a maintainer should confirm the boundary and the escape hatch are what they want.

Level of scrutiny

High. This is production package-manager resolution logic and a security fix, not a mechanical or config change. There are real design choices — reject vs. resolve-relative-to-declarer, whether the root-declares-same-edge escape hatch is desirable, and whether non-optional peers should hard-fail (they already did via ENOENT, and is_required() is !is_optional() which excludes peers, so the behavior is preserved with a clearer message; verify_resolutions skips peers so only the refusal line is logged, matching the peer test). The is_local_package() refactor is behavior-preserving (same three tags in both replaced sites).

Other factors

Test coverage is thorough and pins exact error output, lockfile absence, and node_modules absence for each declarer kind, plus the positive paths (overrides/resolutions, folder declarer, root-declared-too). One finder concern — that optional peers still hit the error path because is_required() treats them as required — was examined and ruled out as matching pre-existing behavior. The comment-cop bot flags on long comments were addressed in db9d41d. No prior human review is on the thread yet and CI status is not shown as complete.

[robobun]

Rebased onto main bf42a52 (was 7aa2b9b, now ecf64ac).

• The conflicts were in src/install/lockfile.rs, src/install/lockfile/Tree.rs and src/install/resolution.rs. In all three, main already has the same code: Lockfile::get_parent_pkg_of_dependency (install: bound isolated store entry names; tarball URL credentials; file: tarballs relative to their folder package #38867), and Tag::is_local_package with its two callers (install: only constrain transitive file: targets of remote packages #33106). The resolution keeps main's text: main's doc comments, and in Tree.rs main's later change from install: do not download tarballs that the installers never place #43122.
• The diff is now 3 files. Tree.rs, resolution.rs and PackageManagerResolution.rs are gone from it. In lockfile.rs, the import line and has_equal_root_dependency remain. The PackageManagerEnqueue.rs hunks and the tests are identical before and after the rebase.
• Checked on a debug build of the rebased branch: the 11 tests of file: tarballs declared by a package installed from the cache pass. On a debug build of main bf42a52, 7 of them fail.
• Also on the branch: 66 other file: / link: / tarball tests of bun-install.test.ts pass, including the ones from install: only constrain transitive file: targets of remote packages #33106 and install: bound isolated store entry names; tarball URL credentials; file: tarballs relative to their folder package #38867. One test in that selection downloads from the public internet and cannot run in my environment.

[claude]

Beyond the inline findings, I also checked the two new index lookups for panics on user-reachable input: declarer comes from enumerating items_dependencies() so [declarer as usize] is in bounds, and has_equal_root_dependency's [0] only runs after that lookup succeeded, so the package list is non-empty. The new bstr::BStr::new uses are Display-only, not a denied byte-search helper.

Extended reasoning...

The Rust change is a ~50-line guard in the Tarball arm of enqueue_dependency_with_main_and_success_fn plus a small Lockfile helper, touching the install resolver's handling of local tarball paths (a path-from-untrusted-manifest surface). Inline findings already cover the gaps in that guard; this note only records the panic and lint concerns examined and ruled out.

Findings marked 🟡 are optional suggestions and need no follow-up push.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟣 src/install/PackageManager/PackageManagerEnqueue.rs — After merging, a registry, git or tarball package can still get a directory of the installing user's choosing (anything under the global link dir, or ../dir beside the project) installed and linked under a name of its choosing via "x": "link:...". The Symlink arm at PackageManagerEnqueue.rs:1597 never looks at the declarer, while the sibling Tarball arm at :1709 now does. Fix: run the same declarer guard (get_parent_pkg_of_dependency + is_local_package) for Tag::Symlink edges, ideally as one shared check before the match so every local-path arm is covered. [also at: src/install/PackageManager/PackageManagerEnqueue.rs:1716 - pre-existing, same class (security): after merging, a registry, git or tarball package can still point bun at a git repository on the installing machine and get it installed under a name of its choosing.]

  Why this was flagged

  A package installed from the registry (or git, or a remote tarball) ships a package.json with "x": "link:some-name" or "x": "link:../dir". Its dependency list is enqueued first-time and reaches the Symlink arm at PackageManagerEnqueue.rs:1597, which calls get_or_put_resolved_package at :3071-3091 with GlobalOrRelative::Global(link_dir). folder_resolver.rs:198-213 resolves a dot-relative path against top_level_dir (the project) and :218-237 resolves a bare name under the user's global link dir; PackageInstaller.rs:1529-1543 then links global_link_dir+path as node_modules/x. Nothing checks who declared the edge, exactly the gap the PR closes for file: tarballs at :1709-1721; the base branch behaves the same, so this is the same class left unfixed, which the repository review rules say must be fixed in the same PR (parallel switch arms). Remedy: apply the declarer guard to the Symlink arm too, or hoist it above the match.

  Verification: The declarer guard exists only in the Tag::Tarball arm (src/install/PackageManager/PackageManagerEnqueue.rs:1709-1720). The Tag::Symlink arm at :1597-1616 calls get_or_put_resolved_package with no look at the declarer. So a cached package can have any directory linked globally installed under a name of its choosing. The diff does not touch the Symlink arm, so merging makes nothing worse.

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

[claude]

Beyond the inline findings, I also checked the two new unreachable!() arms in the Tarball branch of PackageManagerEnqueue.rs (around :1735 and :1753) — local_path is Some on every Uri::Local arm of the match that builds it, so (Uri::Local, None) cannot be constructed; and the resolve_path::join result in locate_next_to_declaring_tarball — it lives in the thread-local JOIN_BUF, the declarer location is joined into a separate pooled buffer, and only string_builder/count/allocate (which grow string_bytes, not the path buffers) run before builder.append copies it.

Extended reasoning...

Findings are posted inline; this note only records that the two unreachable!() arms are unreachable by construction and the JOIN_BUF-backed slice from resolve_path::join is consumed before anything else writes that buffer.

Still open from earlier reviews (2):

• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:1722 — The issue posted at PackageManagerEnqueue.rs:1722 is back: bun install --lockfile-only prints error: refusing to resolv…
• Also unresolved: 1 blocking on lines changed since (possibly already fixed).

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

Still open from earlier reviews (5):

• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:1722 — The issue posted at PackageManagerEnqueue.rs:1722 is back: bun install --lockfile-only prints error: refusing to resolv…
• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:2304 — Monorepo users whose workspace gets a local tarball through a root catalog: entry or an overrides entry get ENOENT for…
• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:2314 — Windows users who commit bun.lock give Linux and macOS teammates an install that fails with ENOENT for every tarball a…
• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:2318 — Projects where a local tarball sits beside a root-declared tarball and is named like x.tgz get a bun.lock bun can no lo…
• Also unresolved: 1 blocking on lines changed since (possibly already fixed).

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟡 src/install/PackageManager/PackageManagerEnqueue.rs — Users who vendor a tarball together with the tarball it depends on get that second tarball installed twice, as two distinct packages, instead of one shared copy as npm gives. Root declares "b": "file:./vendor/b.tgz" and vendor/a.tgz declares "b": "file:./b.tgz"; the located path is the normalized "vendor/b.tgz" while the root row keeps "./vendor/b.tgz", and get_package_id at PackageManagerEnqueue.rs:1739 and the task id at :1756 compare raw strings, so the same file gets two package rows and two node_modules copies. Fix: give every local tarball one canonical identity (normalize the declared root/workspace path the same way as the located one) so equal files dedupe, while keeping the stored row text of existing root rows.

  Why this was flagged

  Trigger: the root package.json declares a: "file:./vendor/a.tgz" and b: "file:./vendor/b.tgz", and vendor/a.tgz's package.json declares b: "file:./b.tgz". Root's b edge enters the Tarball arm with res LocalTarball("./vendor/b.tgz") (PackageManagerEnqueue.rs:1727-1731) and task id for_tarball("./vendor/b.tgz") (:1756), extracting package P1. When a's b edge is enqueued, locate_next_to_declaring_tarball (:2284-2320) joins dirname("./vendor/a.tgz") with "./b.tgz" and resolve_path::join normalizes it to "vendor/b.tgz" (:2314). get_package_id at :1739 compares LocalTarball strings byte-for-byte (resolution.rs:498-501), so P1 is not found; the task id at :1756 differs too, so a second extraction of the same file appends P2 ("b@ vendor/b.tgz"). The user gets node_modules/b and node_modules/a/node_modules/b, two module instances, and two rows in bun.lock. npm resolves both edges to the same realpath and installs one copy. The base branch failed with ENOENT for this layout, so the PR turns a failure into a duplicated install rather than the single-copy install it says it matches.

  Verification: The root b edge keeps the literal "./vendor/b.tgz" as the LocalTarball resolution (PackageManagerEnqueue.rs:1725, :1756). a's b edge is joined through Path::resolve_path::join, which normalizes away the ./ (:2283-2318). get_package_id at :1739 dedupes via Resolution::eql, a raw byte comparison (resolution.rs:498-501), so the same file is extracted twice and appended as two package rows.

[robobun]

Results of a pre-merge run of this pull request at 0c3890c (the head 2586207 differs from it only in two comments), on Linux x64, release and ASan builds, beside main 4b02e10 and 1.4.2. I relay them here because they are not all in a review thread. I did not re-run them.

What the move to a stored location closes. bun update now keeps what bun install did in the posted three-tarball case (3 of 3). Two files no longer share one lockfile row. A lockfile that main or 1.4.2 wrote installs what main installed. The guard is as tight as before: a package from the cache gets no local tarball in any cell.

1. CI. Buildkite 122377: test/cli/install/bun-install.test.ts:10755 fails on Windows 2019 x64 and on Windows 11 aarch64, at expect(lockfile).toContain('"b": ["b@vendor/nested/b.tgz"'). The stored path is joined with the platform's separator, so one project gets two lockfiles.

2. One file, two packages (new). The stored path has no ./, and the root's own edge to the same file is stored as written (./lib2.tgz). A project that lists its vendored tarballs in the root and lets them name each other installs lib2 twice. Main, 1.4.2 and the previous head print 2 packages installed, this head prints 3, and require gives two different objects.

mkdir t && cd t && export BUN_INSTALL_CACHE_DIR=$PWD/.cache
pack() { rm -rf .p; mkdir -p .p/package; echo "{\"name\":\"$2\",\"version\":\"1.0.0\",\"dependencies\":$3}" > .p/package/package.json; echo 'module.exports = {}' > .p/package/index.js; tar -C .p -czf "$1" package; rm -rf .p; }
pack lib.tgz  lib  '{"lib2":"file:./lib2.tgz"}'
pack lib2.tgz lib2 '{}'
echo '{"name":"app","dependencies":{"lib":"file:./lib.tgz","lib2":"file:./lib2.tgz"}}' > package.json
bun install --linker hoisted 2>&1 | grep installed
grep -o '"[a-z0-9/]*": \["lib2@[^"]*"' bun.lock
echo 'console.log("one lib2 object:", require("lib2") === require(require.resolve("lib2", { paths: [require.resolve("lib")] })))' > main.cjs; bun main.cjs

2b. A row that cannot be read back (same cause). A nested tarball in the project's root is written as b@x.tgz. A name that reads like a version range is refused at the next load: error: Unexpected resolution: x.tgz, warn: Ignoring lockfile at every install, and a cold --frozen-lockfile exits 1. 11 of 40 names tried: x.tgz, X.tgz, x.x.x.tgz, and names that start with = ^ ~ * > <. Main and the previous head read all 40 back as b@./x.tgz.

3. A panic where main gives an error (new). A local tarball whose package.json names file: + 1,365 times ../ + b.tgz (4,100 bytes): panic: range end index 4097 out of range for slice of length 4095, exit 134. With 1,364 repeats: ENOENT, exit 1. Main and the previous head: error: ENOENT extracting tarball from b, exit 1. The site is resolve_path::join (4,096-byte buffer), called from enqueue_dependency_with_main_and_success_fn.

mkdir t && cd t
up=$(printf '../%.0s' $(seq 1 1365))
mkdir -p .p/package vendor
echo "{\"name\":\"a\",\"version\":\"1.0.0\",\"dependencies\":{\"b\":\"file:${up}b.tgz\"}}" > .p/package/package.json
tar -C .p -czf vendor/a.tgz package; rm -rf .p
echo '{"name":"app","dependencies":{"a":"file:./vendor/a.tgz"}}' > package.json
bun install

4. bun update under a file: folder (left from the previous head). fold/ (a file:./fold dependency) names ./v/a.tgz, which names ./b.tgz. bun install exits 0. bun update prints error: ENOENT extracting tarball from b and exits 1, with bun.lock and node_modules untouched. Main cannot install that project at all, so this is a gap in the new half and not a regression.

Also. The description still describes the previous design. A question from the same run: should the stored path use / on every system and keep a leading ./, as the rows that main writes?

[claude]

Still open from earlier reviews (1):

• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:1722 — The issue posted at PackageManagerEnqueue.rs:1722 is back: bun install --lockfile-only prints error: refusing to resolv…

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

[claude]

Code review completed

Nothing new to post: everything this review found is already covered by existing comments on this pull request or didn't merit a separate one.

Still open from earlier reviews (1):

• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:1722 — The issue posted at PackageManagerEnqueue.rs:1722 is back: bun install --lockfile-only prints error: refusing to resolv…

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

[robobun]

Results of a pre-merge run of this pull request at 588baff, on Linux x64, release and ASan builds, beside main 4b02e10, 1.4.2 and the previous head 2586207. I relay them with the scripts. I did not re-run them.

What this head repairs. CI is green (Buildkite 122413), including both Windows lanes. The ./-spelled "one file, two packages" case installs 2 packages again. A row such as b@./x.tgz reads back (all 23 stored names). bun update under a file: folder exits 0. The healthy grid equals main in 186 of 186 lines. A member's tarball through catalog:, overrides or resolutions installs. The guard is as tight as before.

Three things are left. Points 1 and 2 have one cause: what the root wrote (x.tgz, ./x.tgz), what a member wrote (relative to the member) and the computed location (relative to the top) share one string namespace.

1. One file, two packages, now for the bare spelling (worse than main). The root writes file:lib2.tgz, so its row is lib2@lib2.tgz. The nested edge is now stored as lib2@./lib2.tgz. Main, 1.4.2 and the previous head print 2 packages installed. This head prints 3 and require gives two objects.

mkdir t && cd t && export BUN_INSTALL_CACHE_DIR=$PWD/.cache
pack() { rm -rf .p; mkdir -p .p/package; echo "{\"name\":\"$2\",\"version\":\"1.0.0\",\"dependencies\":$3}" > .p/package/package.json; echo 'module.exports = {}' > .p/package/index.js; tar -C .p -czf "$1" package; rm -rf .p; }
pack lib.tgz  lib  '{"lib2":"file:lib2.tgz"}'
pack lib2.tgz lib2 '{}'
echo '{"name":"app","dependencies":{"lib":"file:lib.tgz","lib2":"file:lib2.tgz"}}' > package.json
bun install --linker hoisted 2>&1 | grep installed
grep -o '"[a-z0-9/]*": \["lib2@[^"]*"' bun.lock
echo 'console.log("one lib2 object:", require("lib2") === require(require.resolve("lib2", { paths: [require.resolve("lib")] })))' > main.cjs; bun main.cjs

2. The stored location reads like a member's own path (new). vendor/a.tgz names ./b.tgz, stored as ./vendor/b.tgz from the top. A member declares file:./vendor/b.tgz, which is its own packages/m/vendor/b.tgz, a package named q. This head writes "b": ["q@./vendor/b.tgz" and node_modules/b holds q from the member's directory, exit 0. The previous head was right here (b@vendor/b.tgz). Main cannot install this project (ENOENT).

mkdir t && cd t && export BUN_INSTALL_CACHE_DIR=$PWD/.cache
pack() { rm -rf .p; mkdir -p .p/package "$(dirname "$1")"; echo "{\"name\":\"$2\",\"version\":\"1.0.0\",\"dependencies\":$3}" > .p/package/package.json; echo "$1" > .p/package/from.txt; tar -C .p -czf "$1" package; rm -rf .p; }
pack vendor/a.tgz a '{"b":"file:./b.tgz"}'
pack vendor/b.tgz b '{}'
pack packages/m/vendor/b.tgz q '{}'
echo '{"name":"app","workspaces":["packages/*"],"dependencies":{"a":"file:./vendor/a.tgz"}}' > package.json
echo '{"name":"m","version":"1.0.0","dependencies":{"q":"file:./vendor/b.tgz"}}' > packages/m/package.json
bun install --linker hoisted > out.txt 2>&1; echo "exit $?"; cat node_modules/b/from.txt; grep -o '"[a-z/]*": \["[a-z]*@[^"]*b.tgz"' bun.lock

3. The panic is still there. file: + 1,365 times ../ + b.tgz: panic: range end index 4097 out of range for slice of length 4095, exit 134 (script in my previous comment). Main: ENOENT, exit 1. The join moved into a pooled path buffer of the same size, and a length test before the join is still missing.

Also. The description still describes the design before the stored location. A question from the same run: should the identity of a local tarball be the normalized path from the top directory for all three kinds of strings, instead of a prefix on one of them?

[claude]

Still open from earlier reviews (1):

• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:1722 — The issue posted at PackageManagerEnqueue.rs:1722 is back: bun install --lockfile-only prints error: refusing to resolv…

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

[claude]

Code review completed

Nothing new to post: everything this review found is already covered by existing comments on this pull request or didn't merit a separate one.

Still open from earlier reviews (2):

• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:1722 — The issue posted at PackageManagerEnqueue.rs:1722 is back: bun install --lockfile-only prints error: refusing to resolv…
• Also unresolved: 1 minor or pre-existing.

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

[claude]

Code review found no new issues

No new issues were found in this update; 2 findings from earlier reviews are still open above.

Still open from earlier reviews (2):

• 🔴 src/install/PackageManager/PackageManagerEnqueue.rs:1722 — The issue posted at PackageManagerEnqueue.rs:1722 is back: bun install --lockfile-only prints error: refusing to resolv…
• Also unresolved: 1 minor or pre-existing.

If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.

[Jarred-Sumner]

This is Claude (an AI assistant) writing on Jarred's behalf.

Included in #44968, in a different form: the refusal; reading a local tarball's own tarballs from next to it is not in.