Config evaluation works through pnpm symlink layouts; engine 0.2.1 (#222)

## What

Any project whose `node_modules` reaches `@prisma/cli-engine` through a
pnpm symlink that is not realpath'd — this repo's own dev checkout, and
any install with `hoist=false` in `.npmrc` — cannot evaluate any
`prisma.config.ts`: every config-reading command fails with
`CLI.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 own `import "pathe"` walks up from the symlink path and misses
c12's store siblings.

## Changes

- **The fix:** the engine imports c12 through its real path
(`import.meta.resolve` → `realpathSync` → `pathToFileURL`). Evaluation
errors still surface as the existing unreadable-config diagnostic.
- **Import purity:** the module lexer cannot see `import.meta.resolve`,
so the engine's conformance subjects excuse c12 explicitly via
`allowedUnimported: ["c12"]` (conformance script ×2, engine conformance
test). The tarball check gains the per-package `allowedUnimported`
field.
- **Engine 0.2.1** (`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, #200 → #207).
- The deferred ledger entry tracking this defect is removed.

## Verification

- Dev-layout A/B: with a marked `prisma.config.ts` in a scratch dir,
`node packages/cli/dist/cli.js migration list` built from main fails
with the pathe error; built from this branch it evaluates the config
(remaining error is the expected absent-`orm`-section complaint).
- Packed `@prisma/cli` + engine tarballs installed with pnpm and
`hoist=false`: config evaluates — the previously broken published shape.
- `pnpm run conformance` (packages/cli): **0 failing, 3 allowed** (the
recorded transition mismatches), 5 subjects.
- Engine suite 819 passed; CLI suite 831 passed; conformance package
tests 59 passed; credential-free e2e passed; `check-engine-version.mjs
origin/main`: 0.2.1 consistent; typecheck and grammar green.

## After merge

1. main's publish run ships `@prisma/cli-engine@0.2.1`.
2. prisma/composer and prisma/prisma release `@prisma/composer-cli` and
`@prisma/orm-toolchain` peering 0.2.1.
3. A follow-up PR here pins those releases and empties the exception
list.

🤖 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>

Author: wmadden-electric

.drive/projects/prisma-cli-v8/deferred.md

@@ -93,7 +93,6 @@ composer can use it.
 Running the shipped `prisma` binary against a scratch directory, rather than the ORM family through the test harness, turns up three things. The first is a defect a user hits on their first command.
 
 - **`prisma orm init` scaffolds a project the `prisma` binary cannot read.** It writes `prisma-next.config.ts` — the standalone `prisma-next` bin's config file — and then fails its own last step, `Emit the contract`, with exit 5 and `Config is not a defineConfig result`. Nine files are already on disk at that point. Running any ORM command afterwards fails again, differently: the mounted family reads its configuration from an `orm` section of `prisma.config.ts` (`ormConfigSection`, `packages/1-framework/3-tooling/cli/src/orm/config-section.ts` in prisma/prisma), so it reports `CLI.CONFIG_SECTION_INVALID` and `CONFIG.FILE_NOT_FOUND` — "The orm config section is absent, so prisma-next.config.ts was never evaluated." So `prisma orm init && prisma contract emit` cannot work, and the two config surfaces have different shapes: the section nests the whole config under `orm`, while the scaffolded file exports a `defineConfig` result. Which side moves is the ORM's call; that it is broken today is not in question.
-- **Loading a hand-written `prisma.config.ts` failed with `Cannot find package 'pathe'`**, imported by `c12` from `packages/cli-engine/node_modules/c12`. `c12` declares `pathe` and the package is in the workspace store, so this is probably a pnpm layout artifact of running the built binary from inside the monorepo rather than a shipping defect — **but it is unverified**, and if it does reproduce from a packed tarball then every command that reads a config file is broken on install. Worth one run of the S6 tarball check with a config file present.
 - **The e2e coverage convention excludes all 22 ORM commands on reasoning #171 disproved.** `tests/e2e-coverage.test.ts` excuses them with "Real e2e lives in prisma/prisma (R7); the shell proves composition in orm-mount.test.ts (R8)." prisma/prisma's suite passed throughout the presentations change while the assembled binary exited 2, and `orm-mount.test.ts` proves composition for exactly one command, `migration list`, not per family. The operator's ruling (2026-08-13) is that every mounted command needs a happy path in this repo, precisely because the product repos cannot reproduce the assembled CLI. The exclusion should become a backlog entry once the first item above is fixed and the commands can run at all.
 
 ## A live bug carried out of the port (found closing PR #92, 2026-08-12)

packages/cli-engine/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@prisma/cli-engine",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "description": "The execution engine of the unified Prisma CLI.",
   "type": "module",
   "exports": {

packages/cli-engine/src/config-loader.ts

@@ -26,6 +26,7 @@
  */
 import { existsSync, realpathSync } from "node:fs";
 import { dirname, join, resolve } from "node:path";
+import { fileURLToPath, pathToFileURL } from "node:url";
 import type { Diagnostic } from "./protocol";
 import type { LoadedConfig } from "./runtime";
 import { PRISMA_CONFIG_VERSION } from "./runtime";
@@ -189,7 +190,11 @@ const EVALUATE_ONE_FILE_ONLY = {
  * exact path and must not answer with another.
  */
 async function evaluateConfigFile(path: string): Promise<unknown> {
-  const c12 = await import("c12");
+  // Imported via its realpath: under pnpm symlink layouts c12's own
+  // dependencies are only reachable from its real location in the store.
+  const c12 = await import(
+    pathToFileURL(realpathSync(fileURLToPath(import.meta.resolve("c12")))).href
+  );
   const result = await c12.loadConfig({
     name: "prisma",
     configFile: path,

packages/cli-engine/tests/conformance.test.ts

@@ -31,6 +31,10 @@ describe("conformance: import purity", () => {
         label: "@prisma/cli-engine",
         output,
         manifest,
+        // c12 is reached via import.meta.resolve plus a realpath'd
+        // dynamic import (see config-loader.ts), which the lexer
+        // rightly does not count as an import of the bare specifier.
+        allowedUnimported: ["c12"],
         // Anti-vacuity: a run that swept the wrong directory would
         // otherwise report a clean sweep of nothing.
         requiredSpecifiers: ["@stricli/core"],

packages/cli/package.json

@@ -49,7 +49,7 @@
   },
   "dependencies": {
     "@manypkg/tools": "^2.1.2",
-    "@prisma/cli-engine": "workspace:0.2.0",
+    "@prisma/cli-engine": "workspace:0.2.1",
     "@prisma/composer-cli": "0.12.0",
     "@prisma/compute-sdk": "0.39.0",
     "@prisma/credentials-store": "^7.8.0",

packages/cli/scripts/conformance.ts

@@ -71,6 +71,10 @@ async function importPurity(): Promise<readonly Finding[]> {
     label: "@prisma/cli-engine",
     output: await sweepBuiltOutput(join(ENGINE_DIR, "dist")),
     manifest: await manifest(ENGINE_DIR),
+    // c12 is reached via import.meta.resolve plus a realpath'd dynamic
+    // import (see config-loader.ts), which the lexer rightly does not
+    // count as an import of the bare specifier.
+    allowedUnimported: ["c12"],
     requiredSpecifiers: ["@stricli/core"],
   });
   return [...shell, ...unscoped, ...engine];
@@ -98,18 +102,41 @@ async function tarball(): Promise<readonly Finding[]> {
         {
           name: "@prisma/cli-engine",
           dir: ENGINE_DIR,
+          // Same excuse as check 1: c12 arrives via import.meta.resolve.
+          allowedUnimported: ["c12"],
         },
       ],
       shellPackage: "@prisma/cli",
       enginePackage: "@prisma/cli-engine",
       familyPackages: ["@prisma/composer-cli", "@prisma/orm-toolchain"],
-      // No exceptions. Both families declare @prisma/cli-engine as an
-      // exact peer at the version this repo ships, so one engine
-      // resolves in an install — what ADR 0004 asks for. An entry here
-      // exists only while an engine version transition is in flight
-      // (the engine must publish before a family can peer it), and the
-      // release PR that pins the families' new versions removes it.
-      exceptions: [],
+      // The empty list is the goal state: both families peering the
+      // exact engine version this repo ships, one engine per install
+      // (ADR 0004). The two entries below are an engine version
+      // transition in flight — a family cannot peer an engine version
+      // that is not on the registry, so the engine publishes first and
+      // the mismatch is real until both families release against it.
+      // The entries expire with the versions they name, and the PR
+      // that pins the families' 0.2.1 releases removes them; while
+      // they stand, a release could ship the two-engine install they
+      // describe, which is why they must not outlive the transition.
+      exceptions: [
+        {
+          familyPackage: "@prisma/composer-cli",
+          familyPin: "0.2.0",
+          shellPin: "0.2.1",
+          reason: "engine 0.2.1 must publish before composer-cli can peer it",
+          removeWhen:
+            "composer-cli releases peering 0.2.1 and the follow-up bump PR pins that release",
+        },
+        {
+          familyPackage: "@prisma/orm-toolchain",
+          familyPin: "0.2.0",
+          shellPin: "0.2.1",
+          reason: "engine 0.2.1 must publish before orm-toolchain can peer it",
+          removeWhen:
+            "orm-toolchain releases peering 0.2.1 and the follow-up bump PR pins that release",
+        },
+      ],
       channel: CHANNEL,
       sandboxDir: join(WORK_DIR, "sandbox"),
     },

packages/prisma/package.json

@@ -49,7 +49,7 @@
   },
   "dependencies": {
     "@manypkg/tools": "^2.1.2",
-    "@prisma/cli-engine": "workspace:0.2.0",
+    "@prisma/cli-engine": "workspace:0.2.1",
     "@prisma/composer-cli": "0.12.0",
     "@prisma/compute-sdk": "0.39.0",
     "@prisma/credentials-store": "^7.8.0",