Engine 0.2.0: the changed engine must ship, and CI now forces the bump - #200
Conversation
prisma@8.0.0-rc.4 crashes on import (`npx prisma@next --version`): the CLI was built against engine exports that #183 added and #184 extended, but neither PR bumped the engine version, so the registry's @prisma/cli-engine@0.1.1 — published ten minutes before #183 merged — does not contain them. The registry is immutable, so the changed engine ships as 0.2.0; the next publish run picks it up. test.yml gains an engine-version job: a pull request that changes packages/cli-engine while leaving its version at one the registry already has now fails, with the bump command in the error. That is the check whose absence let rc.4 ship broken. The CLI itself becomes installable again only after both products re-declare their exact engine peer at 0.2.0 and release, and 8.0.0-rc.5 ships depending on those releases. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
|
Warning Review limit reached
Next review available in: 3 minutes Limit details: You’ve used all 1 included review currently available under your plan. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (7)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
commit: |
Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
A family cannot peer an engine version that is not on the registry, so the engine publishes first and the pin mismatch is real until both families release against 0.2.0. The exceptions are keyed on the exact version pair they describe, stay visible in every run, and the 8.0.0-rc.5 bump PR removes them. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
|
The first push failed PR Quality on this repo's own conformance check — correctly: with the engine at 0.2.0 and both products peering 0.1.1, the sandbox install resolves two engines. That mismatch is inherent to any engine transition (a family cannot peer an engine version that is not on the registry yet), so 5ea5d9c adds the two exception entries the conformance machinery was designed with for exactly this case: keyed on the exact 0.1.1/0.2.0 pair, printed in every run as "allowed for now", and removed by the 8.0.0-rc.5 bump PR. While they stand, a premature release could ship the two-engine install they describe — that is the argued cost of the transition, and why the rc.5 PR must remove them. Dev-channel conformance now reports 0 failing, 3 allowed. |
Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
…#209) The check from #200 failed the rc.5 release PR (#207): `pnpm bump-version` rewrites the engine's `@repo/*` devDependencies on every release bump, and devDependencies never ship in the published tarball, so the shipped engine is byte-identical while the check saw "packages/cli-engine changed". A change to the engine's manifest now counts only when something outside `devDependencies` differs. Four new tests pin the comparison. Unblocks #207. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
2 participants
What
npx prisma@next --versioncrashes withSyntaxError: The requested module '@prisma/cli-engine' does not provide an export named 'readActiveAccessToken'.Why: #183 added engine exports and #184 changed the engine further, and neither bumped the engine version. The registry's
@prisma/cli-engine@0.1.1was published ten minutes before #183 merged, and published versions are immutable — soprisma@8.0.0-rc.4imports names the engine it installs does not have. CI could not catch it: the workspace builds against its local engine, which has the exports.Changes
pnpm bump-cli-engine-version minor→ engine 0.2.0 (the delegated spawn protocol changed in feat(engine): support structured delegated output #184, so this is the pre-1.0 breaking bump). The next publish run onmainships it.engine-versionin test.yml, backed byscripts/check-engine-version.mjs+ tests): a PR that changespackages/cli-engine/while leaving its version at one the registry already has fails, with the bump command in the error. This is the check whose absence let rc.4 ship broken.What this does not fix on its own
Both products declare the engine as an exact peer at 0.1.1, and npm fails with
ERESOLVEon the mismatch (verified empirically). The repair sequence is:prisma/composerandprisma/prismare-declare the peer at 0.2.0 and release (composer-cli0.7.1,orm-toolchain8.0.0-rc.3).8.0.0-rc.5— the first version wherenpx prisma@nextworks again.🤖 Generated with Claude Code