Findings No. 70
`bun pm pack` writes a `workspace:^` dependency at the version in bun.lock, and a version bump leaves that stale
bun pm pack takes a workspace dependency's version from bun.lock, which bun install never refreshes, so a packed package can ask for an old range.
Preparing the first release of @barmark/render, the packed package.json depended on barmark@^0.1.0. The workspace's barmark was already at 0.2.0, and the renderer needs its form and parts, which 0.1.0 lacks. Under semver, ^0.1.0 excludes 0.2.0, so every install of the packed renderer would have pulled the wrong barmark. It was caught before publish.
The source manifest says "barmark": "workspace:^". Packing with Bun was already a deliberate choice: npm pack copies a workspace: range into the tarball unchanged, and npm cannot install it. bun pm pack rewrites the range, and it takes the version from the workspace package's entry in bun.lock. Bumping barmark's package.json for 0.2.0 left that lockfile entry at 0.1.0. Neither bun install nor bun install --lockfile-only updates a workspace package's version there, and a CI install with --frozen-lockfile does not flag the mismatch.
The fix has two parts. The release checklist now bumps the version in the package's bun.lock entry along with its package.json. The verify:package script, which packs each package and inspects the result, now fails when a packed dependency on a workspace package is anything other than ^ that package's current version. It already failed when a workspace: range survived packing.
General rule: when a pack step rewrites workspace ranges, read the packed manifest back and compare each range with the dependency's real version. A stale lockfile entry passes every install check.
Receipt: barmark commit ea2c137 (scripts/verify-package.ts, RELEASING.md, bun.lock; FINDINGS.md, "bun pm pack takes a workspace dependency's version from bun.lock", and the earlier entry "npm pack would publish workspace:* as written").