fix(bun): Preserve overrides objects, trustedDependencies, workspace bins and git integrity through prune; accept lockfileVersion 3

[Jarred-Sumner]

Description

Bun's next release changes a few things about bun.lock that crates/turborepo-lockfiles/src/bun/ does not handle yet, and while going through the format we found a handful of existing fields that turbo prune drops or rewrites into a shape Bun does not read. This PR fixes all of them in one pass over the Bun parser/emitter; every item is independent and small.

Background on the Bun side:

• lockfileVersion: 2 shipped in install: bump default lockfileVersion to 2, gate stricter parse checks behind it oven-sh/bun#31539 and turbo accepts it since feat: Accept Bun lockfile version 2 #13119 (2.10.3). install: pnpm parity — dedupe, prune, pm licenses, audit fix, add --filter/--catalog, nested overrides, transitive update, and workspace fixes oven-sh/bun#38333 (the upcoming package-manager work) does not change the text format further.

• The next Bun release adds nested overrides: rules scoped to the dependencies of one parent package. They are stored inside the existing overrides section as object values, and the file is stamped lockfileVersion: 3 only when at least one such rule exists (it goes back to 2 when they are removed). Objects are accepted by Bun's reader at every version. The shape is:

  "overrides": {
    "lodash": "4.17.21",                               // flat rule, unchanged
    "micromatch": { ".": "4.0.5", "picomatch": "2.3.2" }, // "." = flat rule for micromatch itself
    "webpack@^4": { "terser": "4.8.1" },              // only applies under webpack matching ^4
  },

  Today either the object value (invalid type: map, expected a string) or the version stamp makes BunLockfile::from_str fail, so the lockfile is treated as absent and turbo prune errors with Cannot prune without parsed lockfile as soon as a repo adds one nested rule.

1. Object values in overrides, lockfileVersion: 3

overrides is now Map<String, OverrideValue> with an untagged string-or-object value. Prune keeps copying the whole section verbatim, exactly as it already does for flat overrides (subgraph.rs): Bun's --frozen-lockfile diffs the complete override set in the lockfile against the root package.json, which prune also copies verbatim, so trimming any rule (flat or nested) would fail pruned installs. apply_overrides applies string rules and an object's "." entry; keys carrying a parent range ("webpack@^4") never match a bare name, and nested child rules need no resolution logic in turbo because Bun materializes them as nested lockfile keys (webpack/terser), which resolution already follows.

LockfileVersion::V3 is added. Versions above the newest known one now parse with a tracing::warn! instead of an error, since every Bun revision so far has only added to the schema and the npm/pnpm parsers in this crate already behave that way; negative versions are still rejected. Adding or removing the first nested rule flips 2 <-> 3 and therefore registers as a global lockfile change once each; that seems correct and is left as is.

2. trustedDependencies copied verbatim on prune

Prune currently emits the section empty. Bun diffs the lockfile's trustedDependencies against the set declared in the (verbatim-copied) package.json files on every install, so an empty section registers every declared entry as newly added. On released Bun versions this is only bookkeeping (--frozen-lockfile does not compare it), but Bun's next release uses "did the manifest diff report anything" to decide how aggressively to clean the tree before the frozen comparison, which can turn that spurious diff into a visible difference; that signal is expected to be tightened on the Bun side as well, but copying the section is the consistent choice either way and matches how overrides/catalog(s) are handled. Trade-off worth knowing: if the only declarer of a trusted name was a workspace that got pruned away (the bun-v1-issue-12744 fixture declares it in apps/bot), the copied entry is now reported as removed instead of nothing being reported. Bun's frozen check compares the resolved tree, not this section, so neither variant should affect bun install --frozen-lockfile on released Bun versions, and the root package.json is the documented place for the field.

3. Workspace-level bin / binDir

Bun writes a workspace's bin/binDir into its workspaces entry and the installer links workspace bins from there. WorkspaceEntry did not have the fields, so a pruned install linked no bins for workspace packages. They are now carried through (bin is a string or an object).

4. git/github integrity element

git/github entries are [ident, INFO, bun-tag, integrity?]; the deserializer stopped after the bun-tag and the emitter always wrote 3 elements, silently removing the content pin from every git dependency in the pruned lockfile. PackageEntry gains an integrity field that is only read/written for git/github entries.

5. Root workspace name is optional

Bun omits name from the "" workspace entry when the root package.json has no name; WorkspaceEntry.name was required, so such repos failed to parse entirely. It now defaults to empty and is skipped on output, which is also how Bun represents it internally.

6. Local tarball and name@root: entries

PackageIdent::Tarball only matched the literal string tarball (a misreading of the schema comment), so ["bar@./bar-0.0.2.tgz", INFO, integrity] was classified as a registry package and re-emitted as [ident, "", INFO, integrity], which Bun rejects with Expected an object. Tarballs are now recognized the way Bun does it (by .tgz/.tar.gz suffix) and use the existing [ident, INFO, integrity?] path. Similarly name@root: entries were parsed into RootInfo but the emitter never consulted it, and RootInfo.bin could not hold an object bin; they are now written as [ident, { bin, binDir }].

7. turborepo-devtools watcher

RELEVANT_FILES listed bun.lockb but not bun.lock (the package watcher has both), so the devtools graph never rebuilt on text lockfile changes.

Not included: a Bun-generated lockfile-tests fixture. All existing Bun fixtures there pin packageManagerVersion <= 1.3.x, and the v3 shape needs a Bun that is not released yet; happy to add a bun-v2-* fixture now and a bun-v3-nested-overrides one once that release is out, if you want them in this PR or a follow-up.

Testing Instructions

• cargo test -p turborepo-lockfiles (312 passed). New unit tests in bun/test.rs: v3 file with object overrides (parse, "." applied, ranged/nested rules not applied, verbatim through prune, reparse), object overrides at v1, unknown newer version accepted / negative rejected, trustedDependencies through prune, workspace bin/binDir (string, object, binDir) through prune, root workspace without a name, git/github 4-element entries through prune, local tarball / remote tarball / @root: entries (with string, object and no bins) through prune. de.rs/ser.rs gain matching test_cases, types.rs gains tarball/root ident tests.
• cargo test -p turborepo-devtools watcher, cargo test -p turborepo-repository bun.
• cargo fmt, cargo clippy -p turborepo-lockfiles --all-targets clean.
• Not run: the lockfile-tests e2e harness (see above; the encoded shapes asserted in the new tests are copied from what Bun's writer produces).

This PR was written by Claude on behalf of the Bun team; a Bun maintainer is sponsoring it and will respond to review.

[vercel]

@Jarred-Sumner is attempting to deploy a commit to the Internal Apps Team on Vercel.

A member of the Team first needs to authorize it.

[anthonyshew]

LGTM. Thanks, Jarred!