install: keep isolated store entry names within NAME_MAX

[robobun]

Repro

mkdir probe && cd probe
cp <bun repo>/test/cli/install/bar-0.0.2.tgz .
bun -e 'require("fs").writeFileSync("package.json", JSON.stringify({ name: "probe", dependencies: { bar: "./" + "x/../".repeat(130) + "bar-0.0.2.tgz" } }))'
bun install --linker isolated

ENAMETOOLONG: File name too long: failed to link package: bar@./x/../x/../x/../...bar-0.0.2.tgz (link)
Failed to install 1 package

Exit code 1, on bun 1.4.0 and main. The tarball itself is at a valid path (the spec normalizes to ./bar-0.0.2.tgz); a tarball or folder at a really deep relative path, or a remote tarball whose URL is long, fails the same way. The hoisted linker installs all of these (its cache folder for a tarball is a hash of the URL); with the isolated linker there is no workaround other than shortening the spec.

Cause

The isolated linker creates one directory per store entry, node_modules/.bun/<name>@<resolution> (entry::StorePathFormatter in src/install/isolated_install/Store.rs). For npm packages the resolution is the version, but for local and remote tarballs, folders and git dependencies it is the user's path or URL, so the directory name is as long as the spec and mkdir fails once it passes NAME_MAX (255 bytes on Linux and macOS, 255 UTF-16 units on NTFS). The peer-set suffix (+<16 hex>) and, with install.globalStore, the -<entry hash> and .tmp-<suffix> suffixes that the installer appends to the same text make the effective limit lower still.

Fix

StorePathFormatter now formats <name>@<resolution> through a small sink that keeps the first 200 bytes and hashes all of it. A name of at most 200 bytes is emitted unchanged. A longer one is emitted as its first 183 bytes (backed up to a UTF-8 character boundary) followed by + and the 16 hex digit wyhash (seed 0, so Bun.hash(fullName) reproduces it) of the full text; the peer-set suffix is appended after that as before. 200 is 255 - 17 - 17 - 21: NAME_MAX minus the peer suffix, the global store's -<hash>, and the .tmp-<u64 hex> / .old-<u64 hex> staging suffixes, so the worst-case directory name in either store is exactly 255 bytes. The constants in Store.rs spell out that arithmetic.

Why this shape:

• Every consumer (the project-local directory, the <cache>/links/ directory name, the dependency symlink targets, and the entry hash seeded from this text) goes through this one Display impl, so cutting the name there keeps all of them consistent, and the global store needs no separate treatment.
• Names up to 200 bytes are byte-for-byte what they were, so existing installs are not re-linked on upgrade. The only names that change are ones in the 201 to 255 byte range that happened to fit before without peers or the global store; those are re-created once under the new name on the next install. Names over 255 bytes never existed on disk.
• Keeping a readable prefix plus a hash of the whole text, rather than replacing the name with a hash the way the tarball cache does, leaves ls node_modules/.bun readable and keeps the cut name a pure function of the same text, so two specs that share the first 183 bytes still get separate entries. This is also what pnpm does for its virtual store (virtual-store-dir-max-length).

#36973 (open) documents the store layout; if it lands, its entry-name table should get a sentence about this rule. #37469 fixes the hoisted linker's panic on the same inputs and #37462 the path-buffer overflow when reading such a tarball; all three are independent.

Verification

New long store entry names block in test/cli/install/isolated-install.test.ts:

• a local tarball and a folder dependency three 85-byte directories deep (entry names of 277 bytes) install, resolve through node_modules, and a second install reuses the same entries
• a remote tarball with a 230 byte URL served by a local Bun.serve, with install.globalStore enabled: the node_modules/.bun entry has the cut name and links to <cache>/links/<cut name>-<hash>, and the package imports at runtime
• a 200 byte name is kept verbatim while a 201 byte one is cut (pins the threshold)
• two packages whose names only differ after the cut point get two entries, each alias resolving to its own package
• a cut entry with a resolved peer gets +<peer hash> appended after the cut name and links its peer

The expected names are computed in the test with Bun.hash, so they pin the exact derivation. The first two fail with exit code 1 (ENAMETOOLONG) on the unfixed build and the other three fail on the entry name; all five pass with bun bd test, as does the rest of isolated-install.test.ts (67 tests), public-hoist-pattern.test.ts, bun-install-native-binlink.test.ts, config-version.test.ts, bun-install-hardlink-fallback.test.ts, regression/issue/31652.test.ts and the two --linker=isolated tests in bun-add.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: 4 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: 1125dfc6-3b74-4a12-a806-578b666e1aa3

📥 Commits

Reviewing files that changed from the base of the PR and between da3851e and c6e6289.

📒 Files selected for processing (2)

• src/install/isolated_install/Store.rs
• test/cli/install/isolated-install.test.ts

---

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

[robobun]

^{Updated 3:58 AM PT - Aug 11th, 2026}

✅ @robobun, your commit c6e62893f8eba6f8ba03a4292c6dd843f4a47bc8 passed in Build #92171! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 37470

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

bun-37470 --bun

[robobun]

Status: reproduced on bun 1.4.0 and main (54d6d16) with the repro in the description (ENAMETOOLONG ... failed to link package: bar@./x/../... (link), exit 1) and with a local tarball / folder three 85-byte directories deep and a remote tarball with a 230 byte URL. Fix and tests are in this PR; the new tests fail on the unfixed build and pass with it on Linux and on Windows x64 (debug build of this branch, all 5 pass; the deep-directory case goes through paths longer than 260 characters, which is fine). On unfixed Windows the same inputs hang instead of failing; that is a separate make_path problem and is tracked separately.

[claude]

I reviewed this PR and didn't find any bugs. Because it changes the isolated linker's on-disk store entry naming (a layout other consumers key off of) and the author's status note says a Windows run of the test file is still pending, a human look would be worthwhile before landing.

What was reviewed:

• NameSink buffering and UTF-8 boundary backup — the ≤200-byte fast path emits the full input verbatim, and the cut path only reads buf[..≤183], so a multi-byte char straddling the 200-byte buffer edge is never emitted.
• Streaming Wyhash::update is chunk-invariant (guarded by test_iterative_chunked_matches_oneshot in src/wyhash/lib.rs), so the write!-driven chunked hashing matches the tests' one-shot Bun.hash(fullName).
• Suffix arithmetic against Installer.rs: .tmp-{:x} / .old-{:x} take a u64, so ".tmp-".len() + 16 is the true maximum and the worst case (cut 183 + 17 + peer 17 + global 17 + staging 21) is exactly 255.
• The refactor from entries.slice().items_*() to entries.items_*() matches existing usage in the same file (fmt_global_store_path, is_cycle).

Extended reasoning...

Overview

The PR adds a length-capping fmt::Write sink (NameSink) around the isolated linker's StorePathFormatter, so a <name>@<resolution> longer than 200 bytes is emitted as its first ≤183 bytes plus +<16-hex wyhash>. The peer-set suffix is appended after the (possibly cut) name as before. The old fmt body is moved verbatim into a write_name(&mut impl fmt::Write) helper; the only behavioural change is the interposed sink. Five new tests in isolated-install.test.ts pin the exact threshold, the hash derivation (via Bun.hash), collision-by-prefix separation, peer-suffix ordering, and the global-store link name.

Security risks

None identified. The change only shortens directory names derived from user-supplied specs; it does not parse untrusted archive contents, escape a directory root, or alter which package bytes are extracted where. Shortening cannot introduce path traversal, and the hash suffix keeps distinct specs in distinct directories.

Level of scrutiny

Medium-high. This is the isolated linker's on-disk store layout — every consumer (local .bun/<entry>, <cache>/links/<entry>-<hash>, dependency symlink targets, and computeEntryHashes) keys off this one Display impl, so a mistake would mis-link packages rather than fail loudly. Names ≤200 bytes are byte-identical to before, which bounds the blast radius to previously-failing or narrowly-working (201-255 byte) inputs, but the layout is a de-facto stable interface that a maintainer should sign off on.

Other factors

• The implementation checks out on close reading: Wyhash (final4, seed 0) is the same algorithm as Bun.hash, and its streaming update/final_ is chunk-invariant per the existing unit tests, so the fmt-chunked hash equals the one-shot hash the tests compute. The UTF-8 boundary loop terminates (is_on_char_boundary(_, 0) is always true) and only reads bytes fully copied from valid &str inputs. The suffix-length constants match the actual {:x} formatting of u64 values in Installer.rs.
• The author's own status comment says a Windows run of the new tests is still outstanding, and the CI build was just started when this review ran. The tests lean on readlink/readlinkSync for symlink targets, which is an established pattern in this file but is the kind of thing that occasionally needs a Windows branch.
• Test coverage is thorough (threshold pinned at 200/201, prefix-collision case, peer-suffix ordering, global store with staging suffix, second-install idempotence), and the PR description spells out the compatibility story for existing installs.

Given the layout change and the pending Windows verification, deferring to a human reviewer rather than auto-approving.

[robobun]

Windows run done: the five new tests pass on a Windows x64 debug build of this branch (the deep-directory case and the global-store runtime import both go through paths over 260 characters; readlink on the junction/symlink targets works as in the rest of the file). Updated the status comment accordingly.

[robobun]

#38867 applies the same cut-and-hash to the store entry name, but with an 80 byte limit on the resolution part instead of 200 bytes on the whole name@resolution: the isolated store also breaks below NAME_MAX on Windows, where a git dependency's entry (typically 110 to 180 bytes, URL plus commit) pushes the package directory past MAX_PATH, and CreateProcess then refuses it as the cwd of the package's lifecycle scripts (Failed to run script prepare due to error ENOENT). That PR covers the ENAMETOOLONG case from this one as well (a tarball URL past NAME_MAX is one of its tests), and it is rebased on the fmt_store_key / bun pm licenses code that landed since this was opened, so this PR can be closed if #38867 lands.

[robobun]

Closing in favor of #38867.

#38867 applies the same cut-and-hash, but to the resolution part of the entry name (80 bytes kept verbatim, otherwise 63 bytes plus + plus the 16 hex wyhash of the full resolution) instead of to 200 bytes of the whole name@resolution. That also covers the case this PR's bound cannot: on Windows a git dependency's entry of 110 to 180 bytes, well under NAME_MAX, already pushes the package directory past MAX_PATH, and the package's lifecycle scripts then fail to spawn with ENOENT. Cutting inside the resolution also keeps name@ intact, which bun pm prune (split_store_key in src/install/prune.rs) and bun pm licenses now rely on; both landed after this PR was opened, and this branch conflicts with main since fmt_store_key was split out of StorePathFormatter.

Checked with a build of #38867's branch: the repro from this description (./x/../ x130 tarball spec) installs with an 84 byte entry (bar@.+x+..+x+..+...+4cc848e6dd29d08d), where the released build fails with the ENAMETOOLONG above. The deep-directory case from this PR (a local tarball and a folder three 85 byte directories deep, unbounded entry names of 277 bytes, the .bun/node_modules fallback link, and a second install finding the same entries) was not among #38867's tests, so it is carried over there in its naming scheme (474da9d, passed in its CI). The threshold, the two-specs-sharing-a-prefix case and the peer suffix case are covered there at the resolution level, and the remote tarball case by its 290 byte URL test.

One thing this PR's whole-name bound covered that #38867 does not is the package name itself: with #38867 a name longer than 119 bytes with the global store (157 in the project store) can still produce an entry over NAME_MAX once its resolution is cut and the suffixes are appended. That is not among the cases reported here (all of them are long resolutions with short names); it is noted on #38867 in case the bound should be extended to the name part there.