Impact
The per-package floor legs added in 0.8.0 hit the same structural deadlock that #17 fixed for check D: on a Version Packages PR, they try to fetch a workspace version that the PR itself is what publishes.
usetheokit/theokit#533 — the Version PR for theokit@0.57.1:
Pin only this floor success
Reinstall at that floor FAILURE
Build, filtered … skipped
Suite, for the packages … skipped
pinned @theokit/http 0.4.0 under `pnpm.overrides` for pnpm
…
ERR_PNPM_NO_MATCHING_VERSION No matching version found for theokit@0.57.1
The latest release of theokit is "0.57.0".
Two jobs red — @theokit/http@0.4.0, the floor only some packages claim and the — result roll-up.
Why the #17 fix does not cover it
#17 taught check D to pack unpublished siblings from the workspace and substitute them, transitively, with a printed note per substitution. That fix lives in the tarball path.
The floor legs take a different path: Pin only this floor writes pnpm.overrides, then Reinstall at that floor runs a plain pnpm install --no-frozen-lockfile against the registry. The override forces a re-resolution, and the re-resolution asks npm for a workspace version that does not exist there yet.
Same cause, same shape, different step.
Suggested fix
The same three options I listed on #17, in the same order — but option (3) is more attractive here than it was there, because the leg's purpose is a floor claim about a sibling range, and an unpublished sibling is not the thing under test:
- Substitute unpublished workspace siblings from local tarballs, as check D now does.
pnpm.overrides mapping each unpublished sibling to its packed tarball, alongside the floor pin.- Skip the leg for a floor whose reinstall would demand an unpublished sibling, reporting
NOT CHECKED (unpublished sibling in tree) rather than passing — consistent with the untestedFloors precedent, and with what the What this run actually checked step already exists to say.
What must not happen is the leg going green on this: the case it exists to catch is a range whose floor genuinely does not work, and that is indistinguishable from a resolution failure if the reason is not named.
Not blocking, and why I am saying so explicitly
Neither leg is a required context on usetheokit/theokit's main — only dep-check / dependency gate is, and that passes. So #533 proceeds. I am reporting this rather than routing around it because the next repo to cut a release with two interdependent packages will see the same two red jobs and have no way to tell them from a real range defect.
Related
#17 — the same deadlock in check D, fixed in 0.6.0#6 / #16 — the per-package legs these are
Found cutting theokit@0.57.1. No secrets in this report.
Impact
The per-package floor legs added in
0.8.0hit the same structural deadlock that#17fixed for check D: on a Version Packages PR, they try to fetch a workspace version that the PR itself is what publishes.usetheokit/theokit#533— the Version PR fortheokit@0.57.1:Two jobs red —
@theokit/http@0.4.0, the floor only some packages claimand the— resultroll-up.Why the
#17fix does not cover it#17taught check D to pack unpublished siblings from the workspace and substitute them, transitively, with a printed note per substitution. That fix lives in the tarball path.The floor legs take a different path:
Pin only this floorwritespnpm.overrides, thenReinstall at that floorruns a plainpnpm install --no-frozen-lockfileagainst the registry. The override forces a re-resolution, and the re-resolution asks npm for a workspace version that does not exist there yet.Same cause, same shape, different step.
Suggested fix
The same three options I listed on
#17, in the same order — but option (3) is more attractive here than it was there, because the leg's purpose is a floor claim about a sibling range, and an unpublished sibling is not the thing under test:pnpm.overridesmapping each unpublished sibling to its packed tarball, alongside the floor pin.NOT CHECKED (unpublished sibling in tree)rather than passing — consistent with theuntestedFloorsprecedent, and with what theWhat this run actually checkedstep already exists to say.What must not happen is the leg going green on this: the case it exists to catch is a range whose floor genuinely does not work, and that is indistinguishable from a resolution failure if the reason is not named.
Not blocking, and why I am saying so explicitly
Neither leg is a required context on
usetheokit/theokit'smain— onlydep-check / dependency gateis, and that passes. So#533proceeds. I am reporting this rather than routing around it because the next repo to cut a release with two interdependent packages will see the same two red jobs and have no way to tell them from a real range defect.Related
#17— the same deadlock in check D, fixed in0.6.0#6/#16— the per-package legs these areFound cutting
theokit@0.57.1. No secrets in this report.