Composer's configuration is the composer section of prisma.config.ts

[wmadden-electric]

Slice 1 of the one-config-file project (spec and design in prisma/orm#30536). After this PR a Composer project has one config file:

// prisma.config.ts
import { definePrismaConfig } from 'prisma/config';
import { defineConfig as composer } from '@prisma/composer/config';
import { nodeBuild } from '@prisma/composer/node/control';
import { prismaCloud, prismaState } from '@prisma/composer-prisma-cloud/control';

export default definePrismaConfig({
  composer: composer({
    extensions: [prismaCloud(), nodeBuild()],
    state: prismaState(),
  }),
});

deploy and dev read that section. prisma-composer.config.ts is not read by anything. A project that still has it gets, under the engine's section-invalid headline:

CONFIG.FILE_RETIRED  <dir>/prisma-composer.config.ts is no longer read.
Composer reads its configuration only from the `composer` section of prisma.config.ts.
Write `composer: composer({ extensions: [...], state: ... })` in prisma.config.ts, with
`import { defineConfig as composer } from '@prisma/composer/config'`. If the project has a
prisma-composer.config.ts, move its extensions and state into that section and delete the file.

The decision

Composer's configuration is the composer section of prisma.config.ts, written the way the ORM section is written: definePrismaConfig wrapping a defineConfig from @prisma/composer/config. The section validator checks the identifying fields the old loader checked, extensions with a string id and an object nodes each, unique ids, and state with a string extension and a function create, and passes the built descriptors through by reference. Composer's own loader, its walk-up discovery, the configPath pointer field, the c12 dependency and the effect version pre-flight are deleted. This is a breaking change for release-candidate users and ships before GA. ADR-0049 records it.

Why the section used to be a pointer, and why that stops

The section held one field, a path to the second file. Its header said a section validator must be light because it loads with the command tree at start-up. The engine loads validators with the family but only runs them when a command needs config, and the ORM section already holds built descriptors with functions inside. So the second file had no reason to exist.

What follows from one section

The declaring file travels with the value. The deploy runs inside an Alchemy child process that imports the config file itself, so the pipeline needs the file as well as the section. The validator returns both, { value, file }, taking file from the engine's provenance. The section merges whole across a config chain, nearest file wins, so a section always has exactly one declaring file. The generated stack files import that file and read its composer export, and refuse a file that has none.

The programmatic operations take the config. deploy, destroy, dev and log on @prisma/composer/control used to find the config by walking up from the entry. @prisma/composer must not import the engine, so they take a required config: ComposerConfigSource, the same { value, file } shape, and the caller evaluates the file. One shared check runs on both routes, CLI and programmatic, and reports the same findings in the same order, before any container or preflight runs. Guides, skill and ADR-0043 are updated.

The old shape is refused, not migrated. CONFIG.FIELD_RETIRED for a configPath field, CONFIG.FILE_RETIRED for an old file beside the declaring file, CONFIG.SECTION_MISSING when no loaded file declares the section. Each shows the section to write. Moving one object literal does not justify a codemod.

The effect pre-flight is retired. It compared the effect version Alchemy resolves against Composer's pin before evaluating the old file, because Alchemy's peer range >=4.0.0-rc.115 || >=4.0.0 accepts release candidates that remove modules Alchemy imports. That is still true today: alchemy@2.0.0-beta.79 fails at import with effect@4.0.0-rc.118 and works with rc.115. After this PR the engine evaluates the file and reports an import failure as CLI.CONFIG_UNREADABLE with the module error, exit code 2. The case is rare, catastrophic, and only the user's package manager can fix it, so failing fast with the real error is the right behaviour. The pins on effect and its companions stay, and the tarball-resolution CI script keeps proving a clean install resolves one effect that Alchemy loads. It now proves that by importing Alchemy directly instead of running the binary, and its adversarial shape passes only when effect is what broke.

dev watches the config file. It keeps the section it started with. On a real change it says the file changed and dev must be restarted, and pauses rebuilds so the parent and the child never run on different configs.

Everything else follows. All ten examples, the integration test project and the website config carry the section and lose the old file. Three user-facing messages that named the old file now name the section. The Biome cast-count plugin flagged import { defineConfig as composer } as a cast; an import alias is not a cast, so the plugin now matches the type-assertion node only, with a test.

Not in this PR

• The prisma-composer binary still exists and still works on the new section. Its removal and the docs sweep that stops naming it are slice 2.
• dependency-cruiser excludes prisma.config.ts, so control-plane imports in config files are not cruised. Recorded as deferred.
• A deploy that reaches the Alchemy plan stage needs real credentials and is slice 3's manual QA, from the prisma host binary.

Verification

• Root typecheck and lint, cast count unchanged at 21, check:cli-engine-pin, check:family-static-graph, check:skill-packaging, test:scripts, the website content test, and the cli (263), core (239), assemble (9) and Prisma Cloud target (386) suites pass. test/integration passes; one run of the store local-dev proof failed on an emulator port clash under the parallel turbo run and passed alone and on rerun.
• scripts/check-npm-effect-resolution.mjs run with network after building the tarballs: exit 0, all four shapes OK; the adversarial tree fails at the Alchemy import with Schema.TaggedError is not a function.
• Manual QA from examples/orm-demo with the built binary: deploy --help exits 0; a signed-in deploy passes config validation and stops at assemble; the restored old file gives CONFIG.FILE_RETIRED; configPath gives CONFIG.FIELD_RETIRED; a programmatic deploy given the whole config export instead of its composer property is refused with CONFIG.FIELD_UNKNOWN before any preflight.

Alternatives rejected

• An engine hook letting a family veto config evaluation, to keep the friendlier effect message. Nothing else would consume it.
• Composer's commands loading the config themselves after the check. Bypasses the engine's declarative config need for a message on a rare failure.
• Running the check at import time inside @prisma/composer/config. Import sorters put the crashing control import first.
• Making the control-plane entries import Alchemy lazily. A refactor of the lowering layer, not for GA.
• A codemod for the old file. More code than the feature.

Agent: columbo-17

🤖 Generated with Claude Code

[prisma-gizmo]

Warning

Gizmo skipped this review: 120 reviewable files exceeds the 100-file limit. Split the PR or review it manually.

[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: ae8b1d37-8a29-4b4e-a065-cda51cee12e7

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

Autopilot is currently an internal CodeRabbit preview.

---

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

[pkg-pr-new]

Open in StackBlitz

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

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

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

commit: a0ce116