The lockfile still recorded the caret pin 0.1.1 removed #3

2026-08-13T07:26:26Z

enricobuehler commented

2026-08-13 07:26:26 +00:00

Two lines in bun.lock, no resolution changes, no version bump.

What was wrong

0.1.1 pinned effect exactly — 4.0.0-beta.102, no caret — because a caret range on a fast-moving prerelease is what crash-looped this plugin and rom-manager: ^4.0.0-beta.99 resolved beta.106, which had dropped Schema.TaggedErrorClass, and the module threw at import before any plugin code ran.

bun.lock never caught up. Its plugin workspace entry still recorded:

"version": "0.1.0",
"effect": "^4.0.0-beta.102",

so the file --frozen-lockfile trusts still described the exact shape the fix removed, one release after it landed.

What was not wrong

I checked before changing anything, because "caret on an effect beta" reads like a live incident:

Nothing resolves wrongly. The lock's resolution entry pins effect@4.0.0-beta.102. In a clean clone the only effect anywhere in the installed tree is node_modules/.bun/effect@4.0.0-beta.102.
No user is exposed. The published 0.1.1 tarball carries "effect": "4.0.0-beta.102" — I pulled it from the registry and read its package.json.
CI is not broken. bun install --frozen-lockfile passes against the stale file today; bun tolerates workspace-metadata drift rather than failing on it. That tolerance is exactly why this sat unnoticed.

So this is the record, not the runtime. The lockfile is the artifact CI reproduces from and the first thing anyone reads to ask "is the caret hazard still here?" — and it answered yes.

Verified

Regenerating changes exactly two lines and no resolution entry, so the install graph is bit-identical before and after.
bun install --frozen-lockfile passes against the regenerated lock: "Checked 560 installs across 716 packages (no changes)".
Full build job locally: biome check clean, tsc --noEmit clean in contract, plugin and ui, bun test 73 pass / 0 fail, bun run build:all succeeds.

No re-release

bun.lock is not published — the plugin ships files: ["dist"] and the lock lives at the workspace root — so 0.1.1 on the registry is unaffected and needs no new version. The index pin stays at 0.1.1.

Related: playnite carried the same stale-lockfile drift (its entry was stuck at 0.3.0, two releases behind) and was corrected in passing by its 0.4.1 release.

Two lines in `bun.lock`, no resolution changes, no version bump. ## What was wrong `0.1.1` pinned effect exactly — `4.0.0-beta.102`, no caret — because a caret range on a fast-moving prerelease is what crash-looped this plugin and rom-manager: `^4.0.0-beta.99` resolved **beta.106**, which had dropped `Schema.TaggedErrorClass`, and the module threw at import before any plugin code ran. `bun.lock` never caught up. Its `plugin` workspace entry still recorded: ``` "version": "0.1.0", "effect": "^4.0.0-beta.102", ``` so the file `--frozen-lockfile` trusts still described the exact shape the fix removed, one release after it landed. ## What was *not* wrong I checked before changing anything, because "caret on an effect beta" reads like a live incident: - **Nothing resolves wrongly.** The lock's resolution entry pins `effect@4.0.0-beta.102`. In a clean clone the only effect anywhere in the installed tree is `node_modules/.bun/effect@4.0.0-beta.102`. - **No user is exposed.** The published `0.1.1` tarball carries `"effect": "4.0.0-beta.102"` — I pulled it from the registry and read its `package.json`. - **CI is not broken.** `bun install --frozen-lockfile` passes against the *stale* file today; bun tolerates workspace-metadata drift rather than failing on it. That tolerance is exactly why this sat unnoticed. So this is the record, not the runtime. The lockfile is the artifact CI reproduces from and the first thing anyone reads to ask "is the caret hazard still here?" — and it answered yes. ## Verified - Regenerating changes **exactly two lines** and no resolution entry, so the install graph is bit-identical before and after. - `bun install --frozen-lockfile` passes against the regenerated lock: *"Checked 560 installs across 716 packages (no changes)"*. - Full build job locally: `biome check` clean, `tsc --noEmit` clean in **contract**, **plugin** and **ui**, `bun test` **73 pass** / 0 fail, `bun run build:all` succeeds. ## No re-release `bun.lock` is not published — the plugin ships `files: ["dist"]` and the lock lives at the workspace root — so `0.1.1` on the registry is unaffected and needs no new version. The index pin stays at `0.1.1`. Related: playnite carried the same stale-lockfile drift (its entry was stuck at `0.3.0`, two releases behind) and was corrected in passing by its `0.4.1` release.

enricobuehler added 1 commit 2026-08-13 07:26:28 +00:00

fix(deps): the lockfile still recorded the caret pin 0.1.1 removed

CI / build (pull_request) Successful in 1m39s

Details

CI / publish (pull_request) Skipped

Details

189dc05811

0.1.1 pinned effect exactly — `4.0.0-beta.102`, no caret — because a caret
range on a fast-moving prerelease is what crash-looped this plugin and
rom-manager: `^4.0.0-beta.99` resolved beta.106, which had dropped
`Schema.TaggedErrorClass`, and the module threw at import before any plugin
code ran.

bun.lock never caught up. Its `plugin` workspace entry still recorded
`"effect": "^4.0.0-beta.102"` and `"version": "0.1.0"`, so the file that
`--frozen-lockfile` trusts still described the shape the fix removed, one
release after it landed.

Nothing was resolving wrongly. The lock's resolution entry pins
effect@4.0.0-beta.102, verified in a clean clone — the only effect anywhere
in the installed tree is beta.102 — and the published 0.1.1 tarball carries
the exact pin, so no user is exposed. `bun install --frozen-lockfile` also
passes against the stale file today: bun tolerates workspace-metadata drift
rather than failing on it, which is precisely why this sat unnoticed.

What it costs is the record. The lockfile is the artifact CI reproduces
from and the first thing anyone reads to ask "is the caret hazard still
here?" — and it answered yes. Regenerating changes exactly these two lines
and no resolution at all, so the install graph is bit-identical before and
after.

No version bump: bun.lock is not published (the plugin ships `files:
["dist"]`, and the lock is at the workspace root), so 0.1.1 on the registry
is unaffected and needs no re-release.

enricobuehler merged commit e21e7ffdb4 into main

2026-08-13 07:36:31 +00:00

enricobuehler deleted branch fix/lockfile-effect-pin-drift

2026-08-13 07:36:35 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk-plugin-virtualhere#3