Config evaluation works through pnpm symlink layouts; engine 0.2.1 - #222
Merged
Conversation
|
Warning Review limit reachedNext included review available in 46 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (3)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. Summary by CodeRabbit
WalkthroughThe CLI engine now resolves 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
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: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Under pnpm symlink layouts that are not realpath'd (this repo's dev checkout; any install with hoist=false), resolving the bare specifier "c12" lands on a symlink path from which c12's own imports miss its store siblings, and every config file reports CLI.CONFIG_UNREADABLE with "Cannot find package 'pathe'". Importing c12 via import.meta.resolve plus realpath fixes resolution in both layouts; errors still surface as the unreadable-config diagnostic. The module lexer no longer sees a literal import of "c12", so the import-purity checks excuse it explicitly: the engine subject and the engine tarball entry in the CLI's conformance script, and the engine's own conformance test. The tarball check learns a per-package allowedUnimported field for this. Also removes the deferred ledger entry that tracked this defect. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
pnpm bump-cli-engine-version patch — the c12 resolution change is compatible, and published engine versions are immutable, so the changed engine needs a new version. The families on the registry still peer engine 0.2.0, which they must until 0.2.1 publishes, so the tarball check carries two recorded exceptions for the transition; the follow-up PR that pins the families' 0.2.1-peering releases removes them. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
wmadden-electric
force-pushed
the
claude/config-eval-pnpm-symlink-4fa2e0
branch
from
August 24, 2026 13:07
28c9835 to
784c585
Compare
This was referenced Aug 24, 2026
Merged
wmadden
pushed a commit
that referenced
this pull request
Aug 25, 2026
## At a glance ```bash # before this PR merges npm install prisma # -> 7.9.1 (Prisma 7) npm install prisma@next # -> 8.0.0-rc.9 # after this PR merges npm install prisma # -> 8.0.0-rc.10 (the unified v8 CLI) ``` ## The decision We are cutting the bare `prisma` npm name over to the v8 line. Until now, every 8.0.0-rc release published under the `next` dist-tag and `latest` kept serving Prisma 7, so nobody landed on v8 without asking for it. The operator ruled today (2026-08-25) that the RC line is ready to be what a bare `npm install prisma` gets. The version number does not change meaning: we stay on `8.0.0-rc.N` (this release is rc.10), and GitHub Releases remain marked pre-release. Only the dist-tag policy moves. ## How the flip actually happens In this repo, merging a version-bump PR is the act that publishes: the push to `main` carries a changed root version, and the publish workflow ships it under the tag `releaseDistTag()` returns. This PR widens that function so every release — RC or stable — publishes under `latest`. **Merging this PR is therefore the cutover itself**: it bumps rc.9 → rc.10 and the resulting publish moves `latest` on `prisma` and `@prisma/cli` in one deliberate, reviewable act. ## What rc.10 ships (since rc.9) - Config files evaluate correctly when the CLI is reached through pnpm symlink layouts that are not realpath'd (#222) — previously every config-reading command failed with `CLI.CONFIG_UNREADABLE` in those setups. - The engine's CI detector is exported and the skills staleness notice uses it, so Jenkins/TeamCity/Azure pipelines stop seeing the notice in their logs (#224). - The `prisma init` scaffold fixes (#225). - Current command-family releases, both peering the exact engine this repo ships (`@prisma/cli-engine@0.2.3`), so one engine resolves per install and the conformance exception list is empty again: `@prisma/composer-cli@0.14.0` and `@prisma/orm-toolchain@8.0.0-rc.7` (which carries the PostgreSQL temporal-codec representations and the `limit`/`offset` pagination rename). ## What happens to the `next` tag and to v7 users - `next` is retired: the publish path no longer moves it, and `scripts/cutover-dist-tags.sh` (operator-run) removes it from all three names and fixes the engine's stale tags. Text that says `prisma@next` should move to plain `prisma` — after this merge they resolve the same thing anyway, until the tag is removed. - Existing v7 installs are untouched: lockfiles pin resolved versions, and `prisma@7.9.1` stays installable by version. The v7 train's new publish home (`prisma7`) is being handled separately and does not block this. ## Alternatives considered - **A one-off `workflow_dispatch` with `dist-tag: latest`** — moves `latest` once, but every subsequent RC release would publish under `next` again and leave `latest` stale on rc.10. The widened rule makes the routine release path keep `latest` current. - **Waiting for stable `8.0.0`** — the rollout plan always left the flip timing to an operator judgement after an RC soak, not to the stable release; the operator ruled the soak is over. - **Keeping `next` synced to `latest`** — considered so existing `prisma@next` instructions would keep resolving the newest release, and dropped: re-pointing a tag on an already-published version cannot authenticate over OIDC, and npm's granular tokens go no narrower than package write — a standing sync would mean a standing publish-capable token, defeating the repo's OIDC-only invariant. Retiring the tag is the honest alternative. ## Verification Script tests green (33/0 on determine-version-utils). Conformance with the empty exception list: **5 subjects checked, nothing to report**, on both the release and dev channels. Lint and the CLI/engine suites green. 🤖 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>
birhantprkc
pushed a commit
to birhantprkc/prisma
that referenced
this pull request
Aug 25, 2026
…ne@0.2.2 (prisma#30111) prisma-cli published `@prisma/cli-engine@0.2.2`: config evaluation works through pnpm symlink layouts that are not realpath'd (prisma/prisma-cli#222) and the engine's CI detector is exported (prisma/prisma-cli#224). The registry's 0.2.0 predates both; 0.2.1 is skipped — no family released against it. `@prisma/orm-toolchain` declares the engine as an exact peer, so it must release against the engine version the `prisma` bin will ship. - Every `@prisma/cli-engine` reference moves 0.2.0 → 0.2.2 (manifests, fixtures, examples, the init-journey harness literal). - `pnpm bump-version`: 8.0.0-rc.5 → 8.0.0-rc.6, stamped across the workspace. - Release notes at `docs/releases/v8.0.0-rc.6.md` (`check:release-notes --mode pr` passes) plus the matching `CHANGELOG.md` entry, covering prisma#30096 and prisma#30097 — the two PRs merged since rc.5 — and the engine move. - `check:upgrade-coverage` passes in both modes. Merging publishes the release under `latest`, which unblocks the prisma-cli PR that pins it and removes the engine-transition exceptions. The composer half of the train is prisma/composer#256. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Bundled `prisma-8` skills and upgrade guidance are now included in ORM package tarballs. * Skill setup is now handled through `prisma init`. * **Breaking Changes** * PostgreSQL temporal columns now use explicit `Temporal` or text representations instead of `Date`. * `prisma orm init` no longer installs skills or supports `--skip-skills`. * **Documentation** * Added `8.0.0-rc.6` release notes and upgrade instructions, including contract artifact updates and temporal migration examples. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Any project whose
node_modulesreaches@prisma/cli-enginethrough a pnpm symlink that is not realpath'd — this repo's own dev checkout, and any install withhoist=falsein.npmrc— cannot evaluate anyprisma.config.ts: every config-reading command fails withCLI.CONFIG_UNREADABLE/Cannot find package 'pathe' imported from .../cli-engine/node_modules/c12/dist/index.mjs. npm and default-pnpm installs are unaffected.Why: the engine loads c12 lazily with a bare
await import("c12"). When that specifier resolves through a symlink without realpathing, c12's ownimport "pathe"walks up from the symlink path and misses c12's store siblings.Changes
import.meta.resolve→realpathSync→pathToFileURL). Evaluation errors still surface as the existing unreadable-config diagnostic.import.meta.resolve, so the engine's conformance subjects excuse c12 explicitly viaallowedUnimported: ["c12"](conformance script ×2, engine conformance test). The tarball check gains the per-packageallowedUnimportedfield.pnpm bump-cli-engine-version patch): the changed engine must ship under a new version. The registry families still peer 0.2.0, so the tarball check carries two recorded transition exceptions; the follow-up PR that pins the families' 0.2.1-peering releases removes them (same train as the 0.2.0 transition, Engine 0.2.0: the changed engine must ship, and CI now forces the bump #200 → chore(release): bump to 8.0.0-rc.5 #207).Verification
prisma.config.tsin a scratch dir,node packages/cli/dist/cli.js migration listbuilt from main fails with the pathe error; built from this branch it evaluates the config (remaining error is the expected absent-orm-section complaint).@prisma/cli+ engine tarballs installed with pnpm andhoist=false: config evaluates — the previously broken published shape.pnpm run conformance(packages/cli): 0 failing, 3 allowed (the recorded transition mismatches), 5 subjects.check-engine-version.mjs origin/main: 0.2.1 consistent; typecheck and grammar green.After merge
@prisma/cli-engine@0.2.1.@prisma/composer-cliand@prisma/orm-toolchainpeering 0.2.1.🤖 Generated with Claude Code