Three CI jobs run bare `bun install` while the rest use --frozen-lockfile — deliberate, or drift?

[iceteaSA]

Filing this as a question rather than a bug, because either answer is defensible and I cannot tell which one is intended.

.github/workflows/ci.yml installs two different ways:

job	line	install
check-plugin	48	bun install
check-pi-plugin	104	bun install
check-dashboard	129	bun install
(later steps)	160, 193, 233, 298	bun install --frozen-lockfile

bun.lock is committed, so the three unpinned jobs are free to resolve outside it while everything after them is not.

Why I noticed

It produced a real green-local/red-CI split for me. Biome is declared ^2.5.1 in all four package manifests and pinned to 2.5.1 in bun.lock. CI's unpinned install floated it to 2.5.7, whose formatter disagrees with 2.5.1 — Check (plugin) failed on lint with 19 errors, none in any file the PR touched, and the same commit was clean locally. Reproduced by installing 2.5.7 locally against clean master: 19 errors, versus 1 on 2.5.1. Same failure appeared on unrelated PRs at the time, which is what pointed at the toolchain rather than the changes.

The general shape: a patch release of any linter/formatter/type-checker in the ^ range can turn CI red on a commit that changes nothing relevant, and the failure surfaces on whichever PR happens to be open.

The case for leaving it

Floating on the check jobs is an early-warning system — you learn about a breaking toolchain patch from your own CI rather than from a contributor's PR. If that is the intent, this issue is just a note and can be closed; a comment on those three steps saying so would save the next person the same investigation.

The case for pinning

Reproducible CI, and toolchain upgrades become explicit lockfile commits rather than surprises attributed to whoever pushed that day. The cost is losing the early warning, which a scheduled job running unpinned would recover without putting it in every PR's path.

Happy to send the one-line PR if you want the three lines pinned. Not sending one unprompted, since I would be changing a policy rather than fixing a defect.

[alfonso-magic-context]

Drift, not policy — and the git history answers it cleanly: the three bare bun install lines are survivors of the original CI from March (9dd6ecde), while --frozen-lockfile arrived in May with the publish-gating rework (7441801b) and was only applied to the jobs added then. Nobody ever decided the check jobs should float; they just predate the discipline.

Your diagnosis also matches scars on our side: the same biome ^ float has cost us red release-gate rounds with formatter-drift errors in files nothing touched — we absorbed them as pre-release cleanup without tracing the mechanism to the unpinned installs. So: yes, please send the PR pinning the three lines. Toolchain upgrades become explicit lockfile commits, which is the behavior we want; the early-warning property is real but doesn't belong in every contributor's PR path, and we'll accept losing it rather than adding a scheduled job for it now.

Thanks for the investigation quality here — reproducing 19-vs-1 across 2.5.7/2.5.1 against clean master is exactly the evidence that separates drift from policy.

[iceteaSA]

PR up: #299. Thanks for digging out the history — 9dd6ecde (March) vs 7441801b (May) settles it far more cleanly than my "cannot tell which is intended" framing did.

Verified before sending, on a clean master worktree: --frozen-lockfile installs successfully (1447 packages, exit 0), and the resulting node_modules resolves biome 2.5.1 rather than the floated 2.5.7. Repo-wide lint passes under it.

One measurement gotcha worth recording here, since it nearly sent me the wrong way: bunx @biomejs/biome --version still reports 2.5.7 after a frozen install, because bunx resolves from the registry, not node_modules. The lint scripts run biome check . via the package-local binary, which is 2.5.1. If anyone re-checks this, ./node_modules/.bin/biome --version is the instrument that reflects what CI actually executes.

Your note about absorbing formatter-drift rounds as pre-release cleanup is the part I would not have guessed — same mechanism, different symptom, and it means the fix is worth a little more than the one PR suggests.

Also worth flagging: this only closes the hole for lockfile-declared toolchain versions. Anything CI installs outside bun.lock — GitHub Action versions, the bun-version: latest in the setup steps — can still drift the same way. Not proposing anything there; just noting it so a future formatter-drift round is not assumed impossible.