install: explain unsupported bun.lock version and suggest 'bun upgrade'#32465
Conversation
When a bun.lock is written by a newer release than the one parsing it, the failure now names the found version, the highest version this build understands, the running Bun version, and adds a note pointing at 'bun upgrade'. Previously the message was just 'Unknown lockfile version' with no indication of what to do.
|
Updated 3:34 PM PT - Jun 17th, 2026
❌ @robobun, your commit 89d2923 has 1 failures in
🧪 To try this PR locally: bunx bun-pr 32465That installs a local version of the PR into your bun-32465 --bun |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — straightforward error-message improvement with a test.
Extended reasoning...
Overview
This PR improves the error message shown when bun install reads a bun.lock whose lockfileVersion is higher than the running build supports. The change is in src/install/lockfile/bun.lock.rs (one error-emit site swapped from add_error to add_range_error_fmt_with_notes with a formatted message and a bun upgrade note) plus a new integration test in test/cli/install/bun-lock.test.ts.
I verified that lockfile_version_num is already constrained to a non-negative u32 by the preceding block (negative / fractional / non-numeric values hit InvalidLockfileVersion first), and Version::from_int exhaustively matches 0/1/2 — so the only way to reach this branch is a value ≥ 3, making the "created by a newer version of Bun" diagnosis and bun upgrade suggestion always accurate. The helper functions used (add_range_error_fmt_with_notes, bun_ast::range_data, bun_core::Global::package_json_version, Version::CURRENT as u32) all exist and are used the same way elsewhere in the codebase.
Security risks
None. This is a diagnostic-string change on an existing error path; control flow (returning ParseError::UnknownLockfileVersion) is unchanged and no new inputs are trusted.
Level of scrutiny
Low. It's a localized UX/error-message tweak following established logging patterns, with no behavioral change to install resolution. The test's exited == 0 expectation is correct because, absent fail_early, a lockfile parse error logs the message, warns "Ignoring lockfile", and proceeds — with empty dependencies that succeeds.
Other factors
The PR includes a targeted test asserting the new wording and the absence of the old "Unknown lockfile version" string. No outstanding reviewer comments, no prior reviews from me, and the bug-hunting system found nothing.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughIn ChangesUnsupported lockfile version error improvement
Possibly related PRs
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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-lock.test.ts`:
- Around line 863-866: The test assertions for the lockfile version error
(around line 863-866) verify key text phrases but do not validate the version
details part of the diagnostic message (current Bun version and max supported
lockfile version). Add an additional expect assertion that checks for
version-related information in the err string, such as a pattern that matches
the current Bun version number and the maximum supported lockfile version
number, to prevent future regressions from silently dropping this important
diagnostic information.
🪄 Autofix (Beta)
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: e7aa82d7-48f3-4186-bc38-e98b2cd2abc3
📒 Files selected for processing (2)
src/install/lockfile/bun.lock.rstest/cli/install/bun-lock.test.ts
There was a problem hiding this comment.
LGTM — focused error-message improvement on the unsupported-lockfile-version path, with a test.
Extended reasoning...
Overview
This PR touches two files: src/install/lockfile/bun.lock.rs (one error-path block in parse_into_binary_lockfile) and test/cli/install/bun-lock.test.ts (one new test). It replaces the terse "Unknown lockfile version" diagnostic with a formatted range error that names the found version, the running Bun version, the max supported lockfile version (Version::CURRENT as u32), and attaches a "Run 'bun upgrade'" note. Control flow is unchanged — it still returns ParseError::UnknownLockfileVersion, so the caller in install_with_manager.zig continues to print "failed to parse lockfile" / "Ignoring lockfile" and proceed (which is why the test correctly expects exit code 0 with empty dependencies).
I verified the referenced symbols exist with matching signatures: log.add_range_error_fmt_with_notes (src/ast/lib.rs:2017), bun_ast::range_data (src/ast/lib.rs:3104), bun_ast::Range::NONE (src/ast/lib.rs:1467), bun_core::Global::package_json_version (src/bun_core/Global.rs:433), and Version::from_int / Version::CURRENT (src/install/lockfile/bun.lock.rs:120-134). The PR's claim that from_int only returns None for values above CURRENT is accurate — the input is already a validated non-negative u32 by this point, and the earlier "Invalid lockfile version" branch handles non-numeric/negative cases.
Security risks
None. This is a diagnostic-string change on an error path; no parsing semantics, trust boundaries, or filesystem/network behavior change. The version number echoed back is the integer the user already wrote into their own bun.lock.
Level of scrutiny
Low. It only changes user-facing error text on an existing failure path, the return value is identical, and the new call uses an established log helper already used elsewhere (e.g. js_parser/p.rs). The test's toMatch(/This is Bun v\\d+\\.\\d+\\.\\d+/) is robust to the -debug / canary suffix because toMatch does not anchor.
Other factors
The CodeRabbit suggestion to assert the version-details clause was addressed in 89d2923 with two regex assertions; that thread is resolved. No CODEOWNERS cover src/install/lockfile/. The robobun comment shows uniform build-rust failures across many platforms on c79cf49 — given the empty "ci: retrigger" commit and the fact the checked-out Rust is well-formed against current bun_ast/bun_core APIs, that reads as infra rather than a code defect; CI being green is a merge gate, not a code-review blocker for this change.
|
CI status for 89d2923 (build #63177):
The previous run (#63166) failed only on |
|
This message gives slightly misleading advise when the lock file is only valid via the canary version |
3 participants
What
When
bun installencounters abun.lockwritten by a newer release, the error now tells the user what happened and what to do about it.Before
After
The only way
Version::from_intreturnsNoneis when the number is a valid non-negative integer aboveVersion::CURRENT, so "created by a newer version" is always the right diagnosis here. The earlier branch that rejects negative / non-integer / non-numeric values ("Invalid lockfile version") is unchanged.Verification
New test in
test/cli/install/bun-lock.test.tswrites abun.lockwithlockfileVersion: 99, runsbun install, and asserts the message includes the found version, the "newer version of Bun" explanation, and thebun upgradenote.