chore(cli-engine): the Management API SDK becomes a peer dependency

[wmadden-electric]

Purpose of change

@prisma/cli-engine hands the shell a Management API client through ctx.api, and re-exports the SDK's type for it:

// packages/cli-engine/src/management-api.ts
/** The SDK's typed client, re-exported so consumers never import
 *  @prisma/management-api-sdk directly. */
export type ManagementApiClient = SdkClient;

That type belongs to @prisma/management-api-sdk, and until now the engine held that package as an ordinary dependency at an exact version — as did packages/cli and packages/prisma, each independently:

cli-engine  dependencies: @prisma/management-api-sdk = 1.55.0
cli         dependencies: @prisma/management-api-sdk = 1.55.0
prisma      dependencies: @prisma/management-api-sdk = 1.55.0

A package whose public API carries another package's types has a shared type surface. Held as three private copies, the three pins can disagree — and when they disagree, the types stop being the same type. Moving only the shell to a newer SDK produces this, roughly fifteen times over:

src/commands/branch/list.ts(80,9): error TS2345:
  Argument of type 'Client<paths@1.55.0>' is not assignable to
  parameter of type 'Client<paths@1.69.0>'

So the SDK version could only ever move in all three manifests at once. One of the three is the engine, and a changed engine needs a new engine version, and both @prisma/composer-cli and @prisma/orm-toolchain peer-pin the engine exactly — so an SDK bump, a routine act, cost a three-repo release sequence every time. That is what blocked #235 from taking @prisma/management-api-sdk@1.69.0, the version @prisma/compute-sdk@0.42.0 asks for.

What's changed

The engine now declares the SDK the way a shared type surface should be declared:

• cli-engine: @prisma/management-api-sdk moves from dependencies to peerDependencies at ^1.55.0 — a range, not a pin, because the consumer chooses. It stays in devDependencies at the version the workspace supplies so the package still builds and tests standalone.
• cli and prisma keep it as a real dependency and move to 1.69.0. They are the binaries; they install the one copy everyone binds to. All three packages now resolve @prisma+management-api-sdk@1.69.0, and pnpm peers check no longer reports compute-sdk's unmet peer.
• Engine 0.2.3 → 0.3.0, the pre-1.0 breaking slot: consumers of the published engine must now supply the SDK themselves.

After this, moving the SDK touches the two app manifests and nothing else — no engine version, no family republish.

The transition this starts

The engine must publish before a family can peer it, so both families still declare 0.2.3 and conformance reports six pin mismatches. packages/cli/scripts/conformance.ts has a place for exactly this, and its comment prescribes the sequence; both entries are filled in with a removeWhen:

0 failing, 6 allowed, 5 subject(s) checked

Every one prints in full with its reason, including the two copies of the engine that resolve in the sandbox install — the expected shape of a transition rather than a defect. The remaining steps, recorded in the deferred ledger: engine 0.3.0 publishes → both families republish peering 0.3.0 → a release PR here pins them and deletes the two exceptions, restoring the empty list.

Verified: pnpm typecheck, pnpm --filter @prisma/cli test (958 passed), pnpm check:conformance (0 failing), node scripts/check-engine-version.mjs.

Alternatives considered

• Relax @prisma/compute-sdk's peer floor back to ^1.44.0. This was my first proposal and it was wrong. That floor is the one peer dependency in the picture that already works: it correctly reported that this repo was pinned behind. Widening it would have silenced an accurate warning and left the actual cause — three private copies of a shared type — in place.
• Bump all three manifests to 1.69.0 and take the release chain. Fixes today's mismatch and leaves the next one to cost exactly the same. The same engine bump buys the structural fix instead.
• A pnpm override forcing one SDK version. Makes the workspace green while the published engine still declares a version it does not get, so anyone installing @prisma/cli-engine alongside @prisma/compute-sdk reproduces the two-copy break. It hides the problem precisely where it would be felt.
• An exact peer (1.69.0) rather than a range. Recreates the lockstep-bump problem one layer up: every SDK release would force an engine release again.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

Next included review available in 3 minutes.

View limit details

Limit 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.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 2beeb9af-d5e4-4569-8841-8d1c075914cd

📥 Commits

Reviewing files that changed from the base of the PR and between bc502d1 and 3beadca.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (5)

• .drive/projects/prisma-cli-v8/deferred.md
• packages/cli-engine/package.json
• packages/cli/package.json
• packages/cli/scripts/conformance.ts
• packages/prisma/package.json

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[pkg-pr-new]

Open in StackBlitz

npx https://pkg.pr.new/@prisma/cli@236

npx https://pkg.pr.new/@prisma/cli-engine@236

commit: 3beadca