[robobun]

Problem

• bun install with the isolated linker (the default for new projects with workspaces) fails when a registry package's own package.json declares a file: dependency. Installing file-dep@1.0.0 from test/cli/install/registry (it declares "files": "file:./the-files" and ships the-files/ in its tarball) prints

  ENOENT: No such file or directory: failed to link package: files@./the-files (open)
  Failed to install 1 package
  

  and exits 1. The hoisted linker installs the same project (bun 1.4.0 and main).
• When the declared path is file:. (file-dep@1.0.1, self-file-dep in the same registry) the install exits 0 but hardlinks or copies the whole project directory (package.json, bunfig.toml, an in-project cache, everything except node_modules) into node_modules/.bun/files@file+./node_modules/files.
• Cause: install_isolated_packages (src/install/isolated_install.rs, Folder arm) starts an install task for every Resolution::Folder entry, and Step::LinkPackage (src/install/isolated_install/Installer.rs, Folder | Root arm) opens the folder relative to the project directory. That is the right base only for paths written by a manifest in the project. A path declared by a registry manifest is stored as written, relative to the declaring package (Package::from_npm), and the resolver records it as a stub package (PackageManagerEnqueue.rs, Folder arm): the folder only exists inside the installed declaring package. The store key of such an entry (files@file+.+the-files) is also the same for every package declaring that path, so two of them would share one directory.

Fix

• dependency_is_contained_folder (isolated_install.rs) is the one rule: a dependency row is a "contained folder" when it is a file: row declared by a registry, git or tarball package and not covered by a root overrides/resolutions entry (OverrideMap::contains_name, the root-authored trust rule the resolver and the hoisted installer already apply to these paths). Rows declared by the root, a workspace or a local file: package have paths Package::parse rebased onto the project and are not. contained_folders evaluates it once per install into two bitsets: the rows, and the folder packages only such rows resolve to (Entry::nested_folder).
• A nested folder entry gets no task: install_isolated_packages completes it as skipped, the way link: entries already work, and build_store keeps it out of the hidden (.bun/node_modules) and publicHoistPattern name slots so a real package with the same name below still hoists. A path that leaves its package (the resolver refuses to record one, so only an edited or old lockfile gets here) is reported with the hoisted installer's refusing to install dependency ... with unsafe folder path error and counted as a failed package.
• The link is decided per dependency edge, not per folder package. In Installer::symlink_dependencies, a package whose own row is a contained-folder row for the target (folder_is_inside_package) links <its own package directory>/<declared path> (append_nested_folder_path), and only if that directory exists; every other edge to a folder links the folder's store entry as before. This is what makes two cases come out the same on a fresh install and on an install from bun.lock, where rows with the same name and path load as one package: a registry package and the root both declaring the-files (root links the project's copy, the package its own), and two registry packages declaring the same folder name.
• A contained folder is private to its package in the peer walk of build_store as well: the binding walk skips an ancestor's contained-folder rows (a package's own row still satisfies its own peer), and the two places that mirror that walk for deduplication (provides and the propagation after an early dedupe hit) skip them too. Previously a peer dependency below the declaring package was bound to the stub by name and then, with the per-package link above, linked from inside the wrong package; now it falls through to whatever else provides the name (the root's folder, the lockfile's resolution) or stays unbound, which is where the hoisted layout puts it too.
• prune.rs stops listing nested entries as expected store directories, so bun prune removes a files@file+... directory left behind by an earlier install. A node_modules produced by the old behavior is otherwise repaired by the next bun install (relink re-points the links; checked by hand with the 1.4.0 canary followed by this build).
• Why this is right: it is the hoisted installer's behavior for these rows (PackageInstaller.rs installs them from the declaring package's directory, treats a missing folder as nothing to link, refuses escaping paths, and never hoists them) expressed in the store layout, and it is scoped to rows, so folders declared by the project keep their store entries and a registry package whose peer binds to one of those keeps linking to it (pinned by a test).
• Unchanged: a folder dependency still keeps its dependents out of the global virtual store (entry_hash stays 0 and propagates), as before.
• Fixtures: registry/packages/create-file-dep-with-peer-packages.ts generates file-dep-with-peer-on-files@1.0.0 ("files": "file:the-files", depends on peer-on-files) and peer-on-files@1.0.0 (optional peer on files, ships an unrelated the-files/ of its own).
• Verified with test/cli/install/isolated-install.test.ts, transitive file dependencies of registry packages (5 of the 6 fail on the current build; the root-folder peer test passes before and after and pins the boundary):
  • are linked from inside the package that declares them: the seven fixtures of the hoisted test (bun-install-registry.test.ts, transitive file dependencies); asserts the store has no folder entries, every link target and its contents, that require from the store package reaches the folder, then the same after rm -rf node_modules and on a relink of the existing node_modules.
  • a folder declared by the root keeps its store entry when a registry package peer-depends on it.
  • a folder is not bound to a peer dependency below the package containing it: the declaring package links its copy, peer-on-files gets no files link although it ships that path itself, and neither entry gets a peer-hash suffix. Failed with the per-package version of this change.
  • a folder the root also declares ...: root links the project's copy, the package its own, the peer below it the root's; the store listing (including peer hashes) is identical on the fresh install and on the install from bun.lock. Failed with the per-package version of this change.
  • does not take the hoist slots of a real package with the same name: publicHoistPattern and .bun/node_modules both end up holding the npm: package aliased to the same name. Hangs on a debug assertion without the two build_store guards.
  • a folder path escaping its package is refused when it comes from bun.lock: edits the stub row to file:../../../the-files, plants that directory, asserts the error, the exit code and that nothing was linked.
  • test/cli/install/bun-prune.test.ts, isolated: a file: dependency declared by a registry package is not a store entry, a leftover one is removed: fails on the current build and without the prune.rs hunk.
• Also run with this change: isolated-install.test.ts, isolated-relink.test.ts, bun-prune.test.ts, public-hoist-pattern.test.ts, overrides.test.ts, nested-overrides.test.ts, bun-workspaces.test.ts, config-version.test.ts, bun-install-registry.test.ts, and the file:/folder tests of bun-install.test.ts; all pass. cargo check -p bun_install for the Windows and macOS targets passes.
• install: keep file: folder paths declared by git and tarball packages relative to the package #38816 makes git and tarball packages store these paths the way registry packages do; their rows already classify as contained folders here, so they take the same path once it lands. install: read the package.json of a file: dependency declared by a local file: package #38814 and install: only constrain transitive file: targets of remote packages #33106 are about folders declared by local file: packages, which keep their store entries under this change.

Background

• A file: dependency on a directory resolves to Resolution::Folder, whose payload is a path string. Manifests in the project (root, workspaces, local file: packages) store it relative to the project directory; a registry manifest's path is stored exactly as declared, relative to the package that declared it. For those, the resolver does not read the target's package.json (it is not on disk until the declaring package is installed) and records a stub package with just a name and the path, and no dependencies of its own. When bun.lock is loaded, rows with the same name and the same resolution become one package, whatever declared them.
• The isolated linker installs each package once into node_modules/.bun/<name@version>/node_modules/<name> (a store entry) and symlinks the package's dependencies next to it, as node_modules/.bun/<name@version>/node_modules/<dep>. Node and Bun resolve from a file's real path, so a package sees exactly those siblings. .bun/node_modules is a fallback directory that the first entry of each name is linked into; publicHoistPattern additionally links matching names into the project's node_modules.
• build_store turns the lockfile into store entries. Peer dependencies are bound there by walking up the dependent's ancestors looking for a dependency of the same name; an entry whose peers bind differently gets its own store entry, named with a peer-hash suffix, and provides/leaking_peers precompute which names a package's subtree resolves internally so identical subtrees can be deduplicated early. install_isolated_packages then drives every entry through the steps in Installer.rs (link the files, symlink dependencies, wait for dependencies to finish, link bins, run scripts) on a thread pool. Entries with nothing of their own to install (workspaces, link: dependencies) are completed on the main thread as skipped, and a dependent waits for its dependencies to reach that state before linking bins; nested folder entries reuse exactly this path.
• bin_target_escapes_package_dir is the lexical check (absolute path, drive prefix, or .. leaving the directory) that the resolver and the hoisted installer already apply to folder paths declared by packages outside the project.

First version of this PR

The first push decided the link target per folder package: every dependent of a nested folder entry linked <own directory>/<path>. Self-review found two holes, both reproduced: a peer dependency below the declaring package, which build_store bound to the stub by name, was linked from inside the peer-dependent package (its own unrelated directory if it happened to ship the path, nothing otherwise), and a folder declared by both the root and a registry package was linked to the package's own copy on a fresh install but to the project's copy on every install from bun.lock, because the two rows load as one package. The per-edge rule and the peer-walk change above replace it; the two tests marked as failing with the per-package version were added for them.

---

no test proof · iteration 0 · Platform-specific test(s) that do not run on this machine. Deferring to CI, which covers all platforms: test/cli/install/bun-prune.test.ts test/cli/install/isolated-install.test.ts

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 8 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 96e1407d-b9de-48b5-b52b-759f2e5b1a37

📥 Commits

Reviewing files that changed from the base of the PR and between 732491c and a579cc3.

📒 Files selected for processing (11)

• src/install/isolated_install.rs
• src/install/isolated_install/Installer.rs
• src/install/isolated_install/Store.rs
• src/install/prune.rs
• test/cli/install/bun-prune.test.ts
• test/cli/install/isolated-install.test.ts
• test/cli/install/registry/packages/create-file-dep-with-peer-packages.ts
• test/cli/install/registry/packages/file-dep-with-peer-on-files/file-dep-with-peer-on-files-1.0.0.tgz
• test/cli/install/registry/packages/file-dep-with-peer-on-files/package.json
• test/cli/install/registry/packages/peer-on-files/package.json
• test/cli/install/registry/packages/peer-on-files/peer-on-files-1.0.0.tgz

---

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

[robobun]

Status: ready for review.

CI on a579cc3 (build 97971): 176 jobs passed; the one red lane is test/regression/issue/09041.test.ts on debian 13 x64-asan, a heap-use-after-free in a bun run child reading stdin through the shell, which nothing in this diff (isolated linker + prune only) touches; it has been handed to main-break triage. The two macOS 14 aarch64 test shards are still waiting for an agent, as they did on the previous build.

Reproduced with the file-dep, missing-file-dep, @scoped/file-dep, @another-scope/file-dep, aliased-file-dep (npm:file-dep@1.0.1) and self-file-dep fixtures from test/cli/install/registry installed with linker = "isolated": bun 1.4.0 and main exit 1 with ENOENT: ... failed to link package: files@./the-files (open) for the first four, and the two file:. packages copy the project directory into node_modules/.bun/files@file+./. The hoisted linker installs the same project.

Tests: test/cli/install/isolated-install.test.ts (transitive file dependencies of registry packages, 6 tests) and test/cli/install/bun-prune.test.ts (isolated: a file: dependency declared by a registry package ...); both files fail on the current build and pass with this branch.

[claude]

I reviewed this PR and didn't find any bugs. Because it changes the isolated linker's store layout for a whole class of file: dependencies and threads a new classification (nested_folder) through build_store, install dispatch, symlink linking, and prune, a human look would still be worthwhile.

What was reviewed:

• nested_folder_packages classification against Root/Workspace/Folder declarers and the overrides name check — matches the hoisted installer's trust rule.
• Path-escape guard: both the entry-level refusal and append_nested_folder_path reuse bin_target_escapes_package_dir; the length check before append_join avoids the panic path.
• Checked that skipping hoisted and publicHoistPattern for nested entries is consistent with them having no store directory to link, and that the entry_hash == 0 (no global store) invariant still holds for these entries.

Extended reasoning...

Overview

The PR fixes bun install --linker isolated for registry packages that declare file: dependencies pointing inside their own tarball. It adds a nested_folder_packages() classifier in isolated_install.rs, a nested_folder: bool column on store::entry::Entry, skips install tasks for those entries in install_isolated_packages (with an unsafe-path refusal mirroring the hoisted installer), and has Installer::symlink_dependencies link each dependent's copy from inside its own package directory via a new append_nested_folder_path helper. prune.rs is updated to stop treating these entries as expected store directories. Tests cover fresh install, reinstall from bun.lock, relink, a root-declared folder satisfying a registry peer, an escaping path from an edited lockfile, and prune of a leftover directory.

Security risks

There is a path-traversal surface: a file:../../.. folder path from a lockfile could point outside the package. Both the entry-level check in install_isolated_packages and the per-dependent append_nested_folder_path reuse the existing lexical bin_target_escapes_package_dir guard (absolute path, drive prefix, .. depth), which is the same rule the resolver and hoisted installer already apply to these paths. The check is lexical rather than realpath-based, but the target lives inside the package's own extracted store directory, so it is consistent with existing behavior rather than introducing a new class of exposure.

Level of scrutiny

This is a behavioral change to the package manager's isolated linker — a production-critical layout path that is now the default for workspace projects. It carries several non-obvious design decisions: which declarers count as "in the project" (Root/Workspace/Folder plus root overrides), that a nested folder is never hoisted or public-hoisted, that entry_node_modules_name == None (root/workspace declarers) silently skips the link, and that a missing shipped folder is treated as nothing-to-link. The PR description argues each of these against the hoisted installer's precedent, and the tests pin the boundaries, but they still merit a maintainer's confirmation of intent.

Other factors

No prior reviewer comments beyond a rate-limited CodeRabbit notice. The diff is ~230 lines of Rust across four files plus ~200 lines of tests; the tests are thorough and mirror the existing hoisted-linker "transitive file dependencies" suite. Cross-platform check (cargo check for Windows/macOS) is claimed in the description. Given the scope and the design content, I'm deferring rather than approving.

[robobun]

^{Updated 4:45 AM PT - Aug 15th, 2026}

⏳ @robobun, your commit a579cc3 is still building in Build #97971, but has 1 failures so far (All Failures):

• test/regression/issue/09041.test.ts - pid 13142 error: addresssanitizer on 🐧 13 x64-asan

[robobun]

Follow-up after self-review (79633be, plus comment trims in f4dc379 and a579cc3; the PR description now describes the current state):

• The link target is now decided per dependency edge (folder_is_inside_package: the dependent's own file: row) instead of per folder package. With the first version, a folder declared by both the root and a registry package was linked differently on a fresh install and on an install from bun.lock, where the two rows load as one package.
• build_store no longer binds a peer dependency below the declaring package to that package's folder (binding walk plus the two dedupe bookkeeping sites that mirror it). With the first version such a peer was linked from inside the peer-dependent package itself.
• New registry fixtures (file-dep-with-peer-on-files, peer-on-files, generated by create-file-dep-with-peer-packages.ts) and three more tests: the peer case, the shared-row case (store listing identical fresh and from the lockfile), and the hoist slots (publicHoistPattern + .bun/node_modules), the last of which pins the two build_store guards that were previously untested.

The comment-cop threads were on the doc comments of the new items; they have been cut down to what each item is and resolved.

[claude]

I reviewed this PR and the bug-hunting pass found no issues. Because it changes the isolated linker's peer-resolution walk in build_store (three sites) and the per-edge link-target decision in symlink_dependencies — core install-path logic whose correctness the author already had to revise once (per-package → per-edge) — a human look is still warranted.

Checked: the path-escape guard reuses bin_target_escapes_package_dir (same check as the hoisted installer and resolver); the new nested_folder field is threaded through Entry/multi_array_columns/Default and consumed in prune.rs; contained_folders correctly unsets the package bit when any non-contained edge resolves to the same folder; append_nested_folder_path bounds-checks the untrusted path length before appending.

Extended reasoning...

Overview

This PR fixes bun install --linker isolated when a registry (or git/tarball) package declares a file: dependency in its own package.json. Previously such folders were opened relative to the project directory (ENOENT), or for file:. copied the whole project into the store. The fix introduces a per-dependency-edge classification (dependency_is_contained_folder, ContainedFolders) that marks these rows as "contained folders" — they get no store entry, are excluded from hoist slots and the peer-provider walk, and are linked from inside the declaring package's own store directory in Installer::symlink_dependencies. prune.rs is updated to not expect store directories for them. Six new tests in isolated-install.test.ts plus one in bun-prune.test.ts cover the fixture matrix from the hoisted-linker equivalent, peer binding below the declaring package, root-and-registry both declaring the same path (fresh vs from-lockfile), hoist-slot interaction, and the escaping-path refusal.

Security risks

The change handles third-party-declared relative paths that are joined into filesystem link targets. The guards look correct: install_isolated_packages refuses paths where bin_target_escapes_package_dir is true (the same lexical check the resolver and hoisted installer use), and append_nested_folder_path repeats that check plus a MAX_PATH_BYTES bound before append_join. The link is only created if sys::directory_exists_at confirms the target is a directory. The refusal path is tested by editing bun.lock to file:../../../the-files and asserting nothing is linked. No new attack surface is introduced beyond what the hoisted linker already handles for these rows, but path handling in the installer is exactly the kind of code that benefits from a second pair of eyes.

Level of scrutiny

High. The isolated linker is the default for workspace projects, so this is a hot production path. The build_store peer walk is one of the more intricate parts of the install pipeline — three separate sites (the provides bitset, the ancestor binding walk, and the leaking-peers propagation) are modified to skip contained-folder rows, and the correctness of peer-hash suffixing and dedupe depends on all three staying consistent. The author's own self-review already caught two correctness holes in the first version (peer bound to the wrong package, fresh vs from-lockfile divergence), which speaks well of the process but also confirms the logic is subtle.

Other factors

• Test coverage is thorough: reuses the hoisted-linker fixtures, adds two new registry packages for the peer case, asserts store listings/link targets/file contents, and covers fresh install, install from bun.lock, and relink of an existing node_modules.
• The comment-cop bot flagged long doc comments; the author trimmed them in f4dc379/a579cc3 and those threads are resolved.
• CI on an earlier commit (e0c11ce) showed failures; status on the latest push (a579cc3) is not yet visible in the timeline.
• The debug assertions added (nested folder has no dependencies, nested folder only bound to containing packages) encode invariants that would be worth a maintainer confirming as intended long-term contracts.

[robobun]

Follow-up candidate once this lands: the pnpm-lock.yaml importer (src/install/pnpm.rs) writes pnpm's project-relative directory: for every file: folder, including ones only a registry/tarball/git package depends on. pnpm resolved those against the project, which bun cannot express for such a declarer, so the most the importer can do is warn about them. #38990 initially carried that warning but dropped it: pnpm migrations select configVersion 1, so monorepos default to the isolated linker, and on main that linker installs these rows from the project, making the warning wrong for them until this PR's classification is in. With nested_folder_packages available (hoisted onto Lockfile, or exposed from here), the importer can warn for exactly the rows this PR classifies as nested that have a can_enqueue_install_task dependent, and the statement is then true under both linkers. The package-lock.json side did not need this: npm keys those targets inside the package, so #38990 converts them instead.

[Jarred-Sumner]

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

Included in #44968.