[robobun]

Repro

# package.json
{ "name": "sandbox", "workspaces": ["packages/*"],
  "dependencies": { "alpha": "file:./vendor/alpha" } }
# packages/alpha/package.json   { "name": "alpha" }
# vendor/alpha/package.json     { "name": "alpha", "version": "2.0.0" }

$ bun install        # exit 0, but bun.lock now contains
    "packages": {
      "alpha": ["alpha@workspace:packages/alpha"],
      "alpha": ["alpha@file:vendor/alpha", {}],
    }
$ bun install
warn: Duplicate key "alpha" in object literal
warn: Ignoring lockfile
$ bun install --frozen-lockfile
error: Duplicate package path
InvalidLockfile: failed to parse lockfile: 'bun.lock'
error: lockfile had changes, but lockfile is frozen

Every install ignores the lockfile and re-resolves, and frozen installs (CI) are permanently broken. The hoisted and isolated linkers also disagree on which package gets the root node_modules/alpha.

Cause

Folder-resolved dependencies are placed into the tree without going through hoist_dependency (Tree.rs, process_subtree), which is where two same-name dependencies of one node would deduplicate. The root package's dependency list contains both the member's implicit workspace dependency and the explicit file: dependency, so both land in the root node and serialize as the same "packages" key twice.

Fix

The root package's dependencies and the workspace members share one node_modules entry per name, so the collision has to have a single winner. The member wins and the file: dependency resolves to it, which is what npm does for this shape (npm links node_modules/alpha -> packages/alpha and never installs vendor/alpha; npm ci round-trips).

Package::parse_dependency's Tag::Folder arm now rewrites a folder dependency to a workspace dependency when a same-named workspace dependency exists in the list being parsed (only the root package has those) and the folder path does not name the member's directory. A path that does name the member's directory is left alone: both dependencies already resolve to the same package through the folder cache. The rewrite mirrors the Tag::Npm arm's existing workspace rewrite a few lines below, keeping the original literal.

Nothing else changes. The member keeps its root packages key, so the lockfile writer and parser are untouched: on reload the file: dependency maps by name to the workspace package and normalizes to a workspace dependency (map_dep_to_pkg), which is exactly what a fresh parse now produces, so the diff is clean and --frozen-lockfile passes.

An earlier revision of this PR made the explicit dependency win instead, extending the npm-range version-mismatch override ("Override the workspace with the other dependency") and dropping the member's workspace dependency. Review showed that displacing a member to a nested lockfile key (for example "beta/alpha") breaks consumers that assume a member owns its name-keyed root entry: the parser cannot resolve the member's own dependencies from the nested key (re-breaking --frozen-lockfile, the symptom this PR exists to fix), the differ stops noticing the member's package.json edits, and bun add run inside the member writes a mangled entry. A folder path also carries no version constraint, so the version-mismatch rationale behind that override does not apply; following npm avoids inventing a third behavior.

Verification

Six tests in test/cli/install/bun-workspaces.test.ts under workspace and file: dependency sharing a name:

• the repro above: single "alpha" key resolving to the member, stable reinstall, --frozen-lockfile passes
• a member with its own file: dependency plus a workspace:* backref from a sibling: the member's dependency installs and the lockfile round-trips
• the file: folder depending back on the member terminates and round-trips
• a file: path naming the member's directory (relative and absolute spellings) keeps resolving to the workspace
• an aliased file: dependency colliding with another member's name resolves to that member

Four fail on an unmodified build with the duplicate-key output above; the two member-directory spellings pass on both by design. Also verified manually: member package.json edits are picked up, bun add inside the member writes the correct entry, and an optionalDependencies collision with the folder absent still installs the member (all matching release-build behavior before this bug).

bun-workspaces (69), bun-lock (17), isolated-install (62), migrate (21), bun-add (54), bun-lockb (6), bun-pm (18), and the transitive file dependencies registry tests pass locally on Linux. bun-install.test.ts shows only pre-existing network-dependent failures (bitbucket/gitlab), identical on an unmodified build.

Related open PRs in this area: #33156 routes folder placements through hoist_dependency for two deps naming one folder (different shape, compatible), #34688 breaks folder dependency cycles in the tree builder (no overlap). #33168 rewrites file: deps whose path names a member by path; this PR's rewrite is name-keyed and fires only on a root collision, so the two compose, but #33168's "a colliding name pointing at a non-workspace folder stays a folder dependency" test covers the root shape this PR changes and will need its expectation updated to the workspace resolution if it lands second.

---

[review] gate passed · iteration 1 · 2 files touched

fails on main (without fix)

ASAN without fix: 4 FAILED
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/cli/install/bun-workspaces.test.ts
bun test v1.4.0 (90f8a4bc2)

test/cli/install/bun-workspaces.test.ts:
(pass) dependency on workspace without version in package.json [2291.35ms]
(pass) allowing negative workspace patterns [201.53ms]
(pass) dependency on same name as workspace and dist-tag [203.34ms]
302 |     ]);
303 | 
304 |     await runBunInstall(env, packageDir);
305 | 
306 |     const lockfile = await file(join(packageDir, "bun.lock")).text();
307 |     expect(lockfile.match(/"alpha": \[/g)).toHaveLength(1);
                                                 ^
error: expect(received).toHaveLength(expected)

Expected length: 1
Received length: 2

      at <anonymous> (/workspace/bun/test/cli/install/bun-workspaces.test.ts:307:44)
(fail) workspace and file: dependency sharing a name > resolves to the member and the lockfile round-trips [257.56ms]
396 |     ]);
397 | 
398 |     await runBunInstall(env, packageDir);
399 | 
400 |     const lockfile = await file(join(packageDir, "bun.lock")).text();
401 |     expect(lockfile.match(
... (truncated)

release without fix: all passed
bun test v1.4.0-canary.1 (78a3bee55)

test/cli/install/bun-workspaces.test.ts:
(pass) dependency on workspace without version in package.json [81.64ms]
(pass) allowing negative workspace patterns [10.31ms]
(pass) dependency on same name as workspace and dist-tag [9.84ms]
(pass) workspace and file: dependency sharing a name > absolute file: dependency naming the member's directory still links the member [10.90ms]
Saved lockfile
(pass) successfully installs workspace when path already exists in node_modules [11.52ms]
(pass) adding workspace in workspace edits package.json with correct version (workspace:*) [12.29ms]
(pass) workspace and file: dependency sharing a name > relative file: dependency naming the member's directory still links the member [13.08ms]
(pass) workspace aliases > combination [13.23ms]
(pass) workspaces with invalid versions should still install [14.10ms]
(pass) workspace aliases > version range workspace:@org/b@latest and workspace with no version [14.36ms]
(pass) workspace aliases > version range workspace:@org/b@* and workspace with no version [14.49ms]
(pass) workspace and file: dependency sharing a name > aliased file: dependency colliding wit
... (truncated)

passes on PR (with fix)

ASAN with fix: all passed
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/mechgate.xml" test/cli/install/bun-workspaces.test.ts
bun test v1.4.0 (90f8a4bc2)

test/cli/install/bun-workspaces.test.ts:
(pass) dependency on workspace without version in package.json [2276.61ms]
(pass) allowing negative workspace patterns [207.15ms]
(pass) dependency on same name as workspace and dist-tag [209.34ms]
(pass) workspace and file: dependency sharing a name > relative file: dependency naming the member's directory still links the member [262.45ms]
(pass) workspace and file: dependency sharing a name > absolute file: dependency naming the member's directory still links the member [267.96ms]
(pass) successfully installs workspace when path already exists in node_modules [174.91ms]
(pass) workspace and file: dependency sharing a name > resolves to the member and the lockfile round-trips [581.44ms]
(pass) workspace and file: dependency sharing a name > file: dependency folder depending back on the member [566.80ms]
(pass) workspace and file: dependency sharing a name > member with its own dependencies still resolves them [613.88ms]
Saved 
... (truncated)

release with fix: all passed
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped) in 676ms (unchanged)
ninja: Entering directory `/workspace/bun/build/release'
[0/5] cargo bun_bin → libbun_rust.a (--target x86_64-unknown-linux-gnu)

  nightly-2026-07-20-x86_64-unknown-linux-gnu unchanged - rustc 1.99.0-nightly (9f36de775 2026-07-19)

�[1m�[92m   Compiling�[0m bun_core v0.0.0 (/workspace/bun/src/bun_core)
�[1m�[92m   Compiling�[0m bun_errno v0.0.0 (/workspace/bun/src/errno)
�[1m�[92m   Compiling�[0m bun_ptr v0.0.0 (/workspace/bun/src/ptr)
�[1m�[92m   Compiling�[0m bun_boringssl_sys v0.0.0 (/workspace/bun/src/boringssl_sys)
�[1m�[92m   Compiling�[0m bun_safety v0.0.0 (/workspace/bun/src/safety)
�[1m�[92m   Compiling�[0m bun_zlib_sys v0.0.0 (/workspace/bun/src/zlib_sys)
�[1m�[92m   Compiling�[0m bun_cares_sys v0.0.0 (/workspace/bun/src/cares_sys)
�[1m�[92m   Compiling�[0m bun_zstd v0.0.0 (/workspace/bun/src/zstd)
�[1m�[92m   Compiling�[0m bun_picohttp v0.0.0 (/workspace/bun/src/picohttp)
�[1m�[92m   Compiling�[0m bun_brotli v0.0.0 (/workspace/bun/src/brotli)
�[1m�[92m   Compiling�[0m bun_output v0.0.0 (/workspace/bun/src/output)
�[1m�[92m   Compiling�[0m bun_clap 
... (truncated)

diff hotspot

src/install/lockfile/Package.rs         |  50 ++++++++
 test/cli/install/bun-workspaces.test.ts | 199 ++++++++++++++++++++++++++++++++
 2 files changed, 249 insertions(+)

gate history · 2 passed · 0 rejected · iteration 1

evidence per changed file

file                                     reads  edits  tests
src/install/lockfile/Package.rs              6      9      0
test/cli/install/bun-workspaces.test.ts      3      4      0

[coderabbitai]

Walkthrough

Changes

Workspace and file dependency resolution

Layer / File(s)	Summary
Folder dependency override handling src/install/lockfile/Package.rs	Normalizes folder paths for workspace comparison. Replaces mismatched same-name workspace dependencies with explicit folder dependencies.
Lockfile workspace claim reconstruction src/install/lockfile/bun.lock.rs	Claims workspace package entries only when they belong to the workspace. Skips workspace dependencies overridden by non-workspace folder dependencies.
Workspace and file dependency coverage test/cli/install/bun-workspaces.test.ts	Tests file overrides, nested and circular references, directory links, aliases, lockfile stability, and frozen-lockfile installs.

Possibly related PRs

• oven-sh/bun#36360: Both PRs modify dependency-resolution logic in Package.rs, but they address different cases.
• oven-sh/bun#36594: Both PRs modify workspace resolution and related tests, but they cover different dependency-path cases.

Suggested reviewers: jarred-sumner

🚥 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.
Description check	✅ Passed	The description explains the problem, cause, fix, and verification results, including test coverage and known failures.
Title check	✅ Passed	The title clearly identifies the fix for duplicate bun.lock keys caused by a file: dependency sharing a workspace member name.

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/cli/install/bun-workspaces.test.ts`:
- Around line 282-289: Reduce the comment above the workspace dependency test to
state only the durable invariant: an explicitly declared root file dependency
with the same name as a workspace member overrides that member’s implicit
workspace dependency. Remove historical failure details and implementation
history, unless replacing them with a confirmed issue URL.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 14845a93-a83f-40b0-b92d-84bd590e7aa4

📥 Commits

Reviewing files that changed from the base of the PR and between 9008ae7 and 1344057.

📒 Files selected for processing (3)

• src/install/lockfile/Package.rs
• src/install/lockfile/bun.lock.rs
• test/cli/install/bun-workspaces.test.ts

[robobun]

^{Updated 7:05 AM PT - Aug 9th, 2026}

❌ @robobun, your commit 90f8a4b has some failures in Build #90909 (All Failures)

---

🧪   To try this PR locally:

bunx bun-pr 37245

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

bun-37245 --bun

[github-actions]

This PR may be a duplicate of:

1. install: parse a file: dependency on a workspace member as a workspace dependency #33168 - Modifies the same Tag::Folder arm of Package::parse_dependency with the same folder-path-vs-workspace-member-path comparison, for the same collision (a file: dep sharing a workspace member's name) and the same symptom (duplicate bun.lock key, warn: Duplicate key ... in object literal, broken --frozen-lockfile), with tests in the same file.

🤖 Generated with Claude Code

[robobun]

Not a duplicate, though they touch the same Tag::Folder arm. #33168 handles a file: dependency whose path names a workspace member's directory (it becomes a workspace dependency), and its description explicitly leaves the other shape alone: "a name that merely collides with a workspace member but points at a different folder is left alone", with a test guarding that ("a colliding name pointing at a non-workspace folder stays a folder dependency").

This PR fixes exactly that excluded shape: the path points at a different folder, so the dependency cannot resolve to the member, and the two entries collided at the root node_modules. The path-names-the-member shape is deliberately left untouched here (the "file: dependency naming the member's directory still links the member" test), so the two PRs compose: they decide opposite sides of the same comparison and neither changes the other's behavior. If both land, the textual merge conflict in the Tag::Folder arm is mechanical.

[claude]

Beyond the inline finding, I also checked whether the new member_owns_packages_key gate weakens the existing Duplicate workspace name error — it does not: two members sharing a name still both pass the gate (both match <name>@workspace:...) and collide in pkg_map as before. I also checked whether sibling tags (link:, local tarball) hit the same duplicate-key bug — they resolve through different placement paths and are not affected by the folder-placement shortcut this PR fixes.

Extended reasoning...

The inline nit covers the one asymmetry found between the fresh-parse and reload call sites of folder_path_is_workspace_path. The two additional concerns above were raised during review and refuted by tracing the code: the member_owns_packages_key gate returns true for any <name>@workspace:<path> entry, so two workspace members with the same name both attempt to claim the key and the pre-existing duplicate check still fires; and link:/tarball dependencies do not take the Tag::Folder direct-placement path in Tree.rs, so they were never subject to this collision.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/install/lockfile/bun.lock.rs`:
- Around line 3405-3425: The folder-path handling in the overridden dependency
check must use the checked path-join API instead of the unchecked join. In the
block computing `joined` inside the lockfile parsing flow, handle a `None`
result by returning `ParseError::InvalidPackageInfo`; preserve the existing
workspace-path comparison for successful joins, and add a regression test
covering an oversized normalized `file:` path in a malformed text lockfile.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e514802b-ea50-4c0d-b269-22bf60ae7915

📥 Commits

Reviewing files that changed from the base of the PR and between 1344057 and 47a5cfc.

📒 Files selected for processing (3)

• src/install/lockfile/Package.rs
• src/install/lockfile/bun.lock.rs
• test/cli/install/bun-workspaces.test.ts

[robobun]

Revised after a deeper self-review pass. The earlier approach extended the npm-range version-mismatch override to folder dependencies: the explicit file: dependency replaced the member's workspace dependency, displacing the member to a nested lockfile key (for example "beta/alpha") when other members still referenced it. Testing that shape with a member that has dependencies of its own showed the parser cannot resolve them from the nested key, which re-broke --frozen-lockfile, and the displaced member also lost package.json edit detection and confused bun add run inside it.

The current revision resolves the collision the way npm does: the member keeps its root node_modules entry and the colliding file: dependency resolves to it (a folder path carries no version constraint, so the version-mismatch rationale behind the override does not apply). That removes all lockfile parser and writer changes from the diff; the loaded lockfile matches a fresh parse through the existing workspace-dependency normalization. The PR body is updated, and the new member with its own dependencies test pins the shape that failed.

[claude]

Additional findings (outside current diff — PR may have been updated during review):

• 🟡 src/install/lockfile/bun.lock.rs:3417-3422 — The sibling site this mirrors (Package.rs:1751) uses join_abs_string_buf_checked and surfaces a graceful "unsafe folder path" error on overflow, but this call uses the unchecked join_abs_string_buf on dep.version.folder() — a raw file: literal from bun.lock (user-editable file contents). A hand-edited lockfile with a >MAX_PATH_BYTES folder literal panics on a slice bounds check in normalize_string_buf instead of producing the recoverable error the fresh-parse side does. Swapping to _checked and treating None as not-the-member's-directory (return true from the closure) keeps both sites consistent.

  Extended reasoning...

  What the bug is

  Commit 47a5cfc added a join+relativize step to parse_append_dependencies so the reload side mirrors Package::parse_dependency's folder-vs-workspace-path comparison. The comment above it explicitly says "Mirror Package::parse_dependency". However, the fresh-parse side at Package.rs:1751 uses resolve_path::join_abs_string_buf_checked, which returns None when the normalized result exceeds the buffer capacity and surfaces a graceful error:

  let Some(joined) = resolve_path::join_abs_string_buf_checked::<path::platform::Auto>(
      FileSystem::instance().top_level_dir(),
      &mut folder_buf.0,
      &[source.path.name().dir, folder.slice(buf)],
  ) else {
      log.add_error_fmt(source, ..., format_args!("Dependency ... has an unsafe folder path"));
      ...
  };

  The new reload-side call at bun.lock.rs:3418 uses the unchecked resolve_path::join_abs_string_buf, writing into bun_paths::path_buffer_pool::get() (a fixed [u8; MAX_PATH_BYTES]).

  The code path

  dep.version.folder() here is the raw substring after file: from bun.lock's workspaces[""].dependencies.<name> entry, produced by dependency::parse on the lockfile literal without length validation. _join_abs_string_buf heap-allocates a scratch buffer sized to the concatenated input, then calls normalize_string_buf(&temp_buf[..], &mut buf[leading_len..]) to write the normalized result back into the caller's fixed-size buf (resolve_path.rs:1764). normalize_string_generic_tz writes each segment via checked slice indexing (buf[buf_i..buf_i+len].copy_from_slice(...)), which panics when the normalized output exceeds MAX_PATH_BYTES.

  Why existing code doesn't prevent it

  The _checked variant's own doc comment (resolve_path.rs:1611–1615) says: "Use this when parts may contain user-controlled input of arbitrary length." Lockfile contents are user-editable file input, and REVIEW.md's "User-reachable failures are recoverable errors, never panics" rule explicitly lists "file contents" as user-reachable. This is the direct sibling of Package.rs:1751 — the site the new code says it mirrors — so "fix the whole class" applies.

  Step-by-step proof

  1. Hand-edit bun.lock so workspaces[""].dependencies.alpha = "file:" + "a/".repeat(3000) (a ~6KB literal), with a workspace member also named alpha.
  2. bun install reloads the lockfile → parse_append_dependencies with IS_ROOT = true.
  3. The .any() closure matches on name_hash and Tag::Folder, then calls join_abs_string_buf(top_level_dir, &mut abs_buf[..], &[<6KB literal>]).
  4. _join_abs_string_buf allocates a ~6KB scratch buffer, normalizes into &mut abs_buf[leading_len..] where abs_buf is MAX_PATH_BYTES (4096 on Linux).
  5. normalize_string_buf writes segment by segment; at ~4KB it hits buf[buf_i..buf_i+len] with buf_i+len > buf.len() → panic: index out of bounds.
  6. On the fresh-parse side, the same literal in package.json would instead return None from _checked at Package.rs:1751 and surface error: Dependency "alpha" has an unsafe folder path.

  Impact

  Low: Bun-written lockfiles cannot reach this because Package.rs:1751-1764 rejects the over-long path before serialization, so it requires a hand-edited or externally-generated lockfile with a >MAX_PATH_BYTES file: literal and a same-name workspace member. The failure is a clean Rust slice-bounds panic, not memory unsafety. But it's a sibling-site inconsistency in code whose stated purpose is to mirror the checked site.

  Fix

  Swap to join_abs_string_buf_checked and treat None as "not the member's directory" — i.e., return true from the .any() closure so the workspace dep is skipped, matching what happens on a fresh parse where the dependency is rejected before ever reaching the override comparison:

  let Some(joined) = resolve_path::join_abs_string_buf_checked::<resolve_path::platform::Auto>(
      top,
      &mut abs_buf[..],
      &[dep.version.folder().slice(bytes)],
  ) else {
      return true;
  };

[robobun]

That finding is against code the latest revision removed: the reload-side join was part of the earlier override approach, and since 78a3bee the lockfile parser is untouched by this PR (no join of lockfile literals happens there anymore). The checked-join call it should mirror, Package.rs's fresh-parse side, is pre-existing code this PR does not modify.

[claude]

I reviewed the revised approach (78a3bee) and didn't find any bugs. Because this changes resolution semantics for a root file: dependency that collides with a workspace member — a design call the PR itself flipped mid-review — a maintainer sign-off on the "member wins" choice would be worthwhile.

What was reviewed:

• The Tag::Folder rewrite mirrors the existing Tag::Npm arm's parse_with_tag pattern; the collides guard correctly scopes it to the root package (non-root members lack implicit workspace-behavior deps in package_dependencies).
• folder_path_is_workspace_path receives relative, which is already bounds-checked via join_abs_string_buf_checked above, so the unchecked join_string_buf inside the helper cannot overflow.
• The six tests cover the collision, member-with-deps, back-reference, member-directory (relative + absolute), and aliased-name shapes; --frozen-lockfile round-trip is asserted.
• Checked that name_hash for Tag::Folder falls through to external_alias.hash, so the aliased-collision test exercises the right key.

Extended reasoning...

Overview

The PR modifies src/install/lockfile/Package.rs (a ~20-line helper plus a ~24-line block in the Tag::Folder arm of parse_dependency) and adds a six-test describe block to test/cli/install/bun-workspaces.test.ts. The fix resolves a duplicate-key bug in bun.lock when a root file: dependency shares a name with a workspace member: the folder dependency is now rewritten to a workspace dependency at parse time, so the member wins the root node_modules slot (matching npm).

The PR went through a substantial mid-review redesign: an earlier revision made the file: dependency win by displacing the member, which touched bun.lock.rs and was found to break --frozen-lockfile, edit detection, and bun add for the displaced member. The current revision reverses that decision and confines the change to Package.rs. My earlier inline finding on this PR was against the removed bun.lock.rs code and is now moot.

Security risks

None. This is dependency-resolution bookkeeping over paths already validated by the surrounding join_abs_string_buf_checked call; no untrusted input reaches new code that wasn't already reaching the existing Tag::Folder arm.

Level of scrutiny

High. This is core package-manager resolution logic that determines what ends up in node_modules and bun.lock. The change is small and closely mirrors the adjacent Tag::Npm arm's workspace-rewrite pattern, but it encodes a user-visible semantic choice (which package wins the root slot) that the author explicitly reconsidered once already. The PR description also flags a known interaction with open PR #33168 (path-keyed rewrite of the same arm) whose test expectation will need updating depending on merge order. A maintainer familiar with the install subsystem should confirm the "member wins" semantics and the #33168 coordination.

Other factors

• The rewrite is not gated on pm.options.link_workspace_packages the way the Tag::Npm rewrite is; that seems intentional (the collision produces broken lockfiles regardless of that flag, and there is no version constraint to fall back to), but it's a semantic detail worth a maintainer's eye.
• Test coverage is thorough for the shapes described, uses test.concurrent with the file's existing semaphore-gated setupTest harness, asserts lockfile stability across reinstalls, and verifies --frozen-lockfile.
• The bug hunting system found no issues in this revision.

[claude]

I reviewed this revised PR and didn't find any bugs. Because it makes a resolution-semantics decision (workspace member wins over a colliding root file: dependency, following npm) and interacts with three other open PRs in the same Tag::Folder area — including #33168, whose test this PR would flip — a maintainer sign-off on the chosen semantics and PR ordering would be worthwhile.

What was reviewed:

• The new Tag::Folder rewrite mirrors the existing Tag::Npm arm's parse_with_tag + literal-preserving struct move; the collides gate correctly restricts it to lists containing an implicit workspace-behavior dep (root only).
• folder_path_is_workspace_path: uses the path-buffer pool and join_string_buf per convention; the Windows separator comparison direction (normalized \\ vs. posix workspace_path /) matches the doc comment's stated input contract.
• The orphaned string_builder.append for the folder value when the rewrite fires is the same append-only-buffer pattern as the Npm arm.
• The prior revision's bun.lock.rs reload-side mirror (and my earlier finding on it) is gone; the current diff touches only Package.rs and tests.

Extended reasoning...

Overview

The PR now touches only src/install/lockfile/Package.rs (+50 lines: a 19-line folder_path_is_workspace_path helper and a ~30-line block in parse_dependency's Tag::Folder arm) plus ~200 lines of tests in test/cli/install/bun-workspaces.test.ts. This is a substantial simplification from the earlier revision, which also modified the lockfile parser (bun.lock.rs) and writer to make the explicit file: dependency win and displace the workspace member — that approach was abandoned after self-review found it broke --frozen-lockfile for members with their own dependencies.

The current fix rewrites a root file: dependency to a workspace dependency when it name-collides with a member and does not point at that member's directory, so both root deps resolve to the same package and only one lockfile key is written.

Security risks

None identified. The change is confined to package.json dependency-tag interpretation during install; no new untrusted input surface, path traversal, or privilege boundary is introduced. The path comparison in folder_path_is_workspace_path is a normalization-then-byte-compare on already-relativized paths and only gates whether a rewrite is skipped.

Level of scrutiny

Medium-high. The code change is small and closely follows the established Tag::Npm rewrite pattern immediately below it (same dependency::parse_with_tag call shape, same literal-preserving whole-struct move with the identical Drop comment). But it encodes a resolution-semantics choice — "workspace member wins over an explicit root file: dep of the same name" — that is a product decision, not a mechanical bugfix. The PR description justifies it via npm parity and via the failure mode of the alternative, which is convincing, but a maintainer should confirm this is the semantics they want, particularly since #33168 (open) explicitly guards the opposite expectation for this exact shape.

Other factors

• Test coverage is thorough: six tests covering the base repro, a member with its own deps + a sibling backref (the shape that broke the earlier approach), a back-dependency cycle, relative and absolute file: paths naming the member's own directory (the skip-rewrite path), and an aliased collision. The gate evidence shows 4/6 fail on an unmodified build and all pass with the fix on both debug+ASAN and release.
• PR history: my previous inline finding (path-representation mismatch between the two folder_path_is_workspace_path call sites) applied to the reload-side mirror in bun.lock.rs, which no longer exists in this revision. The current single call site receives relative, already relativized against top_level_dir, so that concern is moot.
• Related open work: #33156, #34688, and #33168 all touch adjacent folder-dependency handling. The PR body notes #33168's "colliding name pointing at a non-workspace folder stays a folder dependency" test will need its expectation flipped if this lands first — that coordination is a human call.
• The comment-cop bot flagged the two in-source comments as paragraph-length; the author responded that they document a cross-arm invariant rather than a workaround, and at 5 lines each they mirror the Npm arm's existing comment density.

[robobun]

CI state for the final revision (build 90909 on 90f8a4b): 195 of 196 jobs passed. Every annotated failure is a known-flaky test that passed on retry or alone (verdaccio startup in bun-lockb, inspect-error-leak and worker-terminate-funnels on the ASAN lane, bun-server and serve-http3 on macOS, and similar); none touch install, workspaces, or lockfile code. The earlier require-cache timeout on macOS was reported to main-break triage separately.

The diff itself is src/install/lockfile/Package.rs plus tests, green on Linux and Windows locally, with the six new tests passing and four of them failing on an unmodified build. Ready for a maintainer look at the member-wins semantics.

[Jarred-Sumner]

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

Included in #44968: the workspace member wins over an explicit file: of the same name.