fix(deps): alchemy back to beta.78 so npm stops nesting prisma@8.0.0-rc.15; release v0.29.1

[wmadden-electric]

Composer 0.29.0 makes npm install a second, older Prisma CLI inside Composer. With the current CLI and Composer 0.29.0:

$ npm install prisma@8.0.0-rc.21 @prisma/composer-cli@0.29.0 --ignore-scripts
$ npm ls prisma @prisma/cli-engine --all
+-- @prisma/composer-cli@0.29.0
| +-- @prisma/cli-engine@0.7.0
| +-- @prisma/composer@0.29.0
| | `-- alchemy@2.0.0-beta.81
| |   `-- prisma@8.0.0-rc.15
| |     +-- @prisma/cli-engine@0.4.0
| |     +-- @prisma/composer-cli@0.20.0
| |     `-- @prisma/orm-toolchain@8.0.0-rc.11
| `-- alchemy@2.0.0-beta.81
|   `-- prisma@8.0.0-rc.15
|     +-- @prisma/cli-engine@0.4.0
|     ...
`-- prisma@8.0.0-rc.21

The cause is alchemy. From 2.0.0-beta.80, alchemy declares optional peers on exactly prisma@8.0.0-rc.15 and @prisma/orm-postgres@8.0.0-rc.11. (alchemy wrote catalog: in its peerDependencies, and pnpm turned that into an exact version at publish.) No other prisma version satisfies that peer, so npm nests prisma@8.0.0-rc.15 under alchemy. The Prisma CLI's conformance check then fails on the nested @prisma/cli-engine@0.4.0. This blocks the next CLI release.

Decision: go back to alchemy@2.0.0-beta.78 and the exact effect pins we had before #348, and release this as 0.29.1.

This PR has two commits:

1. fix(deps): reverts the dependency part of Upgrade alchemy to beta.81 and use effect ^4.0.0, dropping the @effect/vitest runtime dependency #348. It restores alchemy@2.0.0-beta.78, effect@4.0.0-rc.115, the exact @effect/* pins, @distilled.cloud/prisma@1.0.0-rc.12, the effect/unstable/http/* import paths, the exact-version rule in check-npm-effect-resolution.mjs, and the docs and skills. ORM 8.0.0-rc.17 and @prisma/cli-engine 0.7.0 from chore(deps): move Composer to Prisma ORM 8.0.0-rc.17 and CLI engine 0.7.0 #345 stay.
2. chore(release): v0.29.1: node scripts/set-version.ts 0.29.1 plus the lockfile, and the auth example's contract, which embeds the version (as in chore(release): v0.29.0 #346). Merging this PR publishes 0.29.1.

After this PR, with the packed tarballs:

$ npm ls prisma @prisma/cli-engine --all
+-- @prisma/composer-cli@0.29.1
| `-- @prisma/cli-engine@0.7.0
+-- @prisma/composer-prisma-cloud@0.29.1
| `-- @prisma/orm-toolchain@8.0.0-rc.17
|   `-- @prisma/cli-engine@0.7.0 deduped
`-- prisma@8.0.0-rc.21
  +-- @prisma/cli-engine@0.6.3
  +-- @prisma/composer-cli@0.28.0
  `-- @prisma/orm-toolchain@8.0.0-rc.16

(I ran this before the version bump, so the tarballs were 0.29.0. The prisma@8.0.0-rc.21 subtree is the CLI's own pins; the next CLI release moves them.) No nested prisma under Composer, only @prisma/cli-engine@0.7.0 under Composer, and one effect copy (4.0.0-rc.115) in the whole tree.

Why beta.78 and not beta.79

beta.79 also lacks the prisma peers, but its alchemy/Prisma entry imports the optional peer @alchemy.run/frontend-frameworks and fails to load without it. Composer imports alchemy/Prisma (the Prisma Cloud descriptors). With beta.79, the local-target tests fail with Cannot find module '@alchemy.run/frontend-frameworks/core'. b5e2518 chose beta.78 over beta.79 for the same reason.

Why the effect pins come back

beta.78 was built against effect@4.0.0-rc.115. It imports effect/unstable/http/*, which effect 4.0 moved to effect/http/*, so it can't run on effect 4.0.x. It also lists @effect/vitest as a runtime dependency with an open range. Without our exact pin, npm picks @effect/vitest@4.0.2, which needs effect ^4.0.2 and pulls a second effect. So @effect/vitest goes back into @prisma/composer's dependencies until we can move to an alchemy without the prisma peers.

Verification

• pnpm build, pnpm typecheck, pnpm lint: pass.
• pnpm test without the integration package: 65/65 tasks pass.
• check:npm-effect-resolution: every healthy npm install resolves one effect@4.0.0-rc.115, and the adversarial tree fails as expected.
• check:cli-engine-pin, check:publish-deps, check:family-static-graph, check:skill-packaging, check:orm-pins: pass.
• test:scripts: 229 pass, 1 fails locally: check-cli-engine-pin-host.test.mjs "fails when the family cannot be resolved from the host" gets ERR_FS_EISDIR from rmSync on its temp fixture. That test doesn't touch dependencies; CI will show whether it's local only.

Alternatives considered

• Fix it upstream in alchemy by making the prisma peers ranges instead of exact versions. That PR is being opened separately, but it can't ship on our schedule. When it does, we can move forward to a newer alchemy and drop the effect pins again.
• beta.79 plus @alchemy.run/frontend-frameworks as a dependency. Rejected: it adds a dependency only to load an entry that beta.78 loads without it, and beta.79 still needs the same effect pins.

Agent: tagore-84

🤖 Generated with Claude Code

[prisma-gizmo]

✅ Gizmo reviewed b23e837 — posted 0 inline comment(s) this pass.

Open findings: none

Change walkthrough

This PR backs @prisma/composer off alchemy@2.0.0-beta.81 to 2.0.0-beta.78 and restores the exact effect@4.0.0-rc.115 / @effect/* pins from before #348, releasing the result as v0.29.1. The motivation is npm dependency resolution: beta.81 declares exact optional peers on prisma@8.0.0-rc.15, which no other prisma version satisfies, so consumer installs nest a second, older Prisma CLI inside Composer and break the CLI's conformance check.

Dependency revert. packages/9-public/composer/package.json and composer-prisma-cloud again pin alchemy@2.0.0-beta.78, effect@4.0.0-rc.115, the exact @effect/* companions (including @effect/vitest as a runtime dependency, needed because beta.78 declares it with an open range), and @distilled.cloud/prisma@1.0.0-rc.12. The ORM 8.0.0-rc.17 and @prisma/cli-engine@0.7.0 pins from #345 are kept, so this is a targeted rollback of the alchemy/effect axis only. The effect/unstable/http/* import paths return alongside the pin, which is self-consistent — beta.78 predates effect 4.0's effect/http/* move.

Guardrails and docs. check-npm-effect-resolution.mjs restores its exact-version rule, so the adversarial-tree check fails if the pins are loosened again. The deploy guide's effect-conflict section keeps the placeholder-based override snippets but renames the placeholder from <required> to <pin> and now defines it inline as Composer's exact effect version, citing 4.0.0-rc.115 in Composer 0.29.1; the surrounding text already directs readers to @prisma/composer's dependencies.effect for the live value.

Failure messaging. The install-timeout diagnostic in check-npm-effect-resolution.mjs was rewritten to tell maintainers where each class of pin belongs: alchemy's regular effect-family dependencies go in @prisma/composer's dependencies (next to @effect/sql-d1), while the optional @effect/platform-* peers go in @prisma/composer-prisma-cloud's dependencies. It closes by pointing at the skills-contrib/upgrade-alchemy-effect skill, which covers exactly this check's failure mode.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 4654eaea-7c18-4768-b2f6-a4e7c7ede777

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@prisma/composer@349

npm i https://pkg.pr.new/@prisma/composer-cli@349

npm i https://pkg.pr.new/@prisma/composer-prisma-cloud@349

commit: b23e837

[prisma-gizmo]

New findings: 🟡 2 minor · trace

[prisma-gizmo]

No critical or major Gizmo finding is open and the head commit has been reviewed. Approving.

[prisma-gizmo]

New findings: none · trace

[prisma-gizmo]

No critical or major Gizmo finding is open and the head commit has been reviewed. Approving.