bun install fails on main: bun.lock missing resolution entry for @types/bun (blocks Lint (Javascript) on all PRs)

[acoliver]

Summary

bun install fails on a pristine checkout of main. The lockfile declares @types/bun as a root dev dependency but contains no resolved entry for it in the packages section, so Bun rejects the whole lockfile.

This currently fails the Lint (Javascript) CI job on every open PR, which in turn skips the entire test matrix (the test job needs lint). Effectively no PR can get a green test run right now.

Reproduction

On a clean worktree of main with no local modifications:

git worktree add /tmp/x main
cd /tmp/x
bun install

Output:

bun install v1.3.14 (0d9b296a)
5 |     "": {
            ^
error: Failed to resolve root dev dependency '@types/bun'
    at bun.lock:5:9
InvalidPackageInfo: failed to parse lockfile: 'bun.lock'
warn: Ignoring lockfile

Bun then falls back to full resolution ("Ignoring lockfile"), which is why some jobs still succeed -- but the CI step is bun install && git checkout -- bun.lock, and the nonzero parse failure surfaces as a job failure.

Root cause

In bun.lock, @types/bun appears only as a version constraint under the root workspace devDependencies:

line 122:  "@types/bun": "1.3.14",

There is no corresponding resolution entry in the packages section. Compare @types/debug, which has both:

line 123:   "@types/debug": "^4.1.12",            <- constraint
line 1409:  "@types/debug": ["@types/debug@4.1.13", ...  <- resolution

A grep for a packages-section entry returns nothing:

grep -n '^\s*"@types/bun"' bun.lock
122:        "@types/bun": "1.3.14",

The package itself is fine on the registry -- npm view @types/bun@1.3.14 version returns 1.3.14, so this is not a yank.

@types/bun was introduced to both package.json and bun.lock in 91e7462 (#2484, "Add Bun/Vitest compatibility shim for bun test runner").

Evidence of impact

Lint (Javascript) across recent CI runs:

30161918570  issue2666  failure
30161800840  issue2688  failure
30161750618  issue2666  failure
30161381617  issue2666  failure
30161260726  issue2683  failure
30160640260  issue2654  success
30158327063  issue2654  success

Recent main runs:

30146622275  6bc801020  2026-07-25T05:56:15Z  success
30130688588  3a12f02e5  2026-07-24T22:21:18Z  success

So main was green earlier and every current PR branch now fails, on branches touching completely unrelated code. Confirmed reproducible on a pristine main worktree, so it is not specific to any PR.

Suggested fix

Regenerate the lockfile so the resolution entry is present:

rm bun.lock && bun install

Then verify bun install exits 0 against the committed lockfile on a clean checkout, and that all 16 workspaces resolve.

Note per dev-docs/bun.md that bun install --frozen-lockfile is not usable in this monorepo; the CI smoke uses plain bun install.

Context

Found while working #2688. Not caused by that PR -- it modifies only .github/workflows/ci.yml and two files under scripts/tests/, and touches no dependency manifest.

[coderabbitai]

🔗 Related PRs

#811 - fix: Add Bun runtime to release workflow #810 [merged]
#1832 - Bootstrap release workflow dependencies in both paths (Fixes #1831) [merged]
#2260 - Adopt Bun as package and workspace manager (Fixes #2238) [merged]
#2470 - feat(test): add Bun-backed root test orchestration entry point (Fixes #2463) [merged]
#2610 - Launch installed CLI directly with bundled Bun (Fixes #2603) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[acoliver]

Additional findings from attempting the fix locally (bun 1.3.14, matching .bun-version).

Both entries are missing, not just one. @types/bun depends on bun-types@1.3.14, and neither has a resolution entry in the packages section:

grep -nE '^\s+"(@types/bun|bun-types)": \[' bun.lock   ->  no matches

Option A: full regeneration (rm bun.lock && bun install) works but is heavy-handed.
Exit 0 and the parse error is gone, but the diff is 180 insertions / 384 deletions and includes unrelated churn:

• configVersion reverts 1 -> 0
• dozens of packages get downgraded, e.g. @ai-sdk/gateway 2.0.109 -> 2.0.105, @ai-sdk/openai 2.0.110 -> 2.0.109, @azure/msal-browser 5.16.0 -> 5.15.0
• some optionalPeers lists shrink (e.g. @a2a-js/sdk loses @grpc/grpc-js and express)

Those downgrades look like a side effect of re-resolving floating ranges at a different moment, not something anyone intended in a lockfile-repair commit.

Option B: surgical insertion also works and is much smaller. Adding just the two missing resolution entries:

"@types/bun": ["@types/bun@1.3.14", "", { "dependencies": { "bun-types": "1.3.14" } }, "sha512-h1hFqFVcvAvD9j9K7ZW7vd82aSA+rTdznZa+5bwvCwqSB1jmmfLcbIWhOLx1/+boy/xmjgCs/OMUL8hRJSmnPw=="],
"bun-types": ["bun-types@1.3.14", "", { "dependencies": { "@types/node": "*" } }, "sha512-4N0ig0fEomHt5R0KCFWjovxow98rIoRwKolrYdCcknNwMekCXRnWEUvgu5soYV8QXtVsrUD8B95MBOZGPvr6KQ=="],

makes bun install exit 0 with the parse error gone. Bun then renormalizes a further ~44 lines (workspace file:packages/* entries, hoisting some mime-types/mime-db and telemetry/storage paths), which is the known renormalization behavior documented in dev-docs/bun.md.

Integrity hashes above are from npm view @types/bun@1.3.14 dist.integrity and npm view bun-types@1.3.14 dist.integrity.

Not bundling this into #2690. That PR is scoped to CI platform coverage and test-harness diagnosability and touches no dependency manifest; mixing in a lockfile repair (especially one that silently downgrades packages) would conflate two unrelated concerns and make review harder. Filing this separately so it can get a focused review — the package downgrades in Option A in particular deserve a deliberate decision rather than riding along in another PR.

Whoever picks this up: Option B seems preferable since it repairs exactly what is broken without changing resolved versions, but it is worth confirming the renormalized workspace entries are acceptable.

[acoliver]

Fixed in #2690 (commit 3882226) via the surgical Option B described above, since this was blocking that PR's test matrix from running at all.

Applied only the two missing resolution entries. Verified zero resolved-version changes against HEAD, so no package was silently upgraded or downgraded; the remaining diff is Bun's workspace renormalization. Clean install, typecheck, and build all pass.

Option A (full regeneration) remains unused — the package downgrades it introduces still warrant a separate deliberate decision if anyone wants to pursue a lockfile refresh.