Repository navigation
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix(bun): accept bun.lock lockfileVersion 2 — bun 1.4 re-versioned an unchanged grammar #224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
fix(bun): accept bun.lock lockfileVersion 2 — bun 1.4 re-versioned an unchanged grammar #224
Changes from 1 commit
42a4b5543c92abbc0c425File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
… unchanged grammar bun 1.4.0 bumped the default bun.lock lockfileVersion to 2 (oven-sh/bun PR #31539). The bump gates stricter PARSE checks — integrity hashes required for off-registry npm tarballs, unsafe git .bun-tag values rejected — behind an UNCHANGED emitted grammar: a 1.3.14 and a 1.4.0 lock of the same fixture are byte-identical except the integer (verified empirically in docker). Our hosted/vendored tuples always carry a sha512, satisfying the new off-registry-integrity rule by construction. CI's hosted-e2e job installs floating bun@1, which now resolves to 1.4.0 — the shared version gate (check_lock_version in bun_lock_text) refused everything but 1, so bun_hosted_install_proof went red on every push to main. Widen the gate to {1, 2}; refuse anything else with the updated fail-closed message. The floating bun@1 is deliberately kept: catching exactly this drift is the hosted suite's job. Covered call sites: redirect rewriter (redirect_bun_lock_unsupported), vendor backend (vendor_lockfile_version_unsupported), lock inventory, plus a v1-only fixture assertion in the vendor bun e2e capstone. New golden fixture npm/bun/lock-v2 (Rust-authored — the depscan TS twin needs the matching acceptance + fixture sync); the existing lock-version-unsupported input re-pinned from 2 to 3 (2 is now supported). No existing expected/ bytes re-blessed. Proofs, all with real bun 1.4.0 on PATH: redirect + vendor e2e capstones green on NATIVE v2 locks (fresh-checkout frozen installs of patched bytes, tamper refusal), and the exact red CI leg bun_hosted_install_proof green against real production. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.