pastilhasandClaude Fable 5
a356656a60
bun 1.4.0 was published 2026-08-20 and https://bun.sh/install serves whatever is newest, so machine-setup provisioning a box today would put a two-day-old release under the platform and every pm2 app except officer-pty. The owner asked for a temporary hold on 1.3. The SERIES is pinned, not a patch — BUN_SERIES=1.3, resolved to the newest 1.3.x at install time so bug fixes inside the series still land, and no 1.3.14 to rot into "the version we happened to pick" the way setup_22.x did for Node. The version reaches the installer as its documented first positional argument (a release tag), and install_bun refuses to run with an empty one: taking whatever bun.sh serves is the single outcome the pin exists to prevent, so no bun at all is the better failure. Loud, and officer-setup's pre-flight already stops on a missing bun. Resolved from the npm registry rather than GitHub's releases API, which is the obvious source and the wrong one — 60 unauthenticated requests an hour per IP, and it returned 504 twice while this was written. An empty answer installs nothing, so where it comes from is load-bearing. The section now reads four states instead of two. "Installed" was one answer covering a machine inside the pin, one behind it, and one past it; past it is the case worth catching, since that is what bun upgrade leaves and nothing else reports it. Above and below get different prose and both offer to move; nothing is corrected silently. What a setup script cannot cover: bun upgrade takes no version argument — latest stable or --canary, verified against its own --help — so it always jumps past the pin without saying so. Hence the doctor check, which reads engines.bun rather than repeating the number, because a second hardcoded copy is a second thing to drift. bun ignores engines (verified: an install declaring 1.9.x ran clean under 1.3.14), so the field is the declaration and doctor is the enforcement. Confirmed bun install --dry-run still resolves frozen with the field present and bun.lock unchanged. This host is already on 1.3.14 and inside the pin, so nothing moved here. Also fixes three more stale process counts in the same block. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1.8 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| infra/revisit-the-bun-1-3-pin-once-1-4-has-been | Revisit the bun 1.3 pin once 1.4 has been watched for a while | infra | open | 2026-08-22 | stated | 6 |
Revisit the bun 1.3 pin once 1.4 has been watched for a while. Raised by the owner 2026-08-22, who asked for it explicitly as a temporary hold — "a few months, until I'm sure the new 1.4 is going to be safe" — so this exists to stop a deliberate pause becoming permanent by nobody remembering it.
bun 1.4.0 was published 2026-08-20 and https://bun.sh/install serves whatever is newest, so a
machine provisioned on 2026-08-22 would have put a two-day-old release under the platform and every
pm2 app except officer-pty. The hold is at the SERIES, not a patch: BUN_SERIES=1.3 in
scripts/setup/machine-setup/lib/dev.sh, resolved to the newest 1.3.x from the npm registry at
install time, so bug fixes inside the series still land.
Two places carry the number and they must move together — BUN_SERIES in dev.sh, and
engines.bun in package.json, which is what bun run doctor reads to decide whether the running
bun has drifted. bun itself ignores engines (verified: an install declaring 1.9.x ran clean under
1.3.14), so that field is a declaration and doctor is the enforcement.
What is NOT covered, and is the reason a drift check exists at all: bun upgrade takes no version
argument — latest-stable or --canary, nothing else — so it always jumps to the newest release and
walks a pinned machine off the pin silently. Nothing in a setup script can prevent that; bun run doctor reports it after the fact, and machine-setup.sh --only 'JavaScript runtimes' offers to pin
it back down.
To lift the hold: raise both numbers, run bun run doctor on each machine, and delete this item.