Resolve the composer section's configPath against the file that declared it

[wmadden-electric]

What changed

The composer config section resolves its configPath against the prisma.config.ts file that declared it, instead of against the directory the command happens to run in.

prisma.config.ts is now a chain rather than a single file: prisma-cli discovers every config file from the command's cwd up to the repo root and merges the sections per key. A composer section written once at the repo root therefore reaches commands run in any subdirectory — and a configPath resolved against the process cwd names a different file in each of them, which is almost never the file the author meant.

The fix follows the pattern engine 0.3.0 defines: the section validator resolves the path-valued key and returns an absolute path, so nothing downstream ever resolves against cwd.

• packages/0-framework/3-tooling/cli/src/family/section.ts — validate takes the section's provenance as its second argument and runs configPath through the engine's resolveSectionPath. An absolute path passes through unchanged. resolveSectionPath throws when the key is missing from the provenance, which cannot happen for a key just read out of the section, but a section validator must never throw — so even that case becomes a CONFIG.FIELD_INVALID diagnostic rather than an internal error blamed on composer.
• src/load-config.ts and src/pipeline.ts — configPath is documented and treated as absolute; the resolution against cwd is gone.
• Engine declarations move to 0.3.0 together (the internal CLI, composer-cli's peer and dev pins, the target extension, and the four examples), which is what check-cli-engine-pin requires.

Tests

• src/family/__tests__/engine-cli.test.ts gains the real regression test: a two-file chain where the root file is the only one declaring configPath, with the run's cwd two directories below it. Both wrong answers are visible — resolving against cwd, or against the nearest file on the chain, would name /repo/apps/shop/prisma-composer.config.ts instead of /repo/prisma-composer.config.ts.
• src/family/__tests__/section.test.ts covers the validator directly: relative resolves against the declaring file, absolute passes through, and a provenance missing the key fails with a diagnostic instead of throwing.
• host-adapter.test.ts asserts the resolved absolute path arrives at the operation, end to end through the real Runtime.
• Reverting the resolution to path.resolve(configPath) (cwd-based) fails 6 of these tests, including both engine-level ones — the tests fail when the behavior breaks.

What is green, and what is not

Verified locally against a packed @prisma/cli-engine@0.3.0 tarball installed into the workspace:

• tsc --noEmit across all 78 workspace typecheck tasks — clean.
• turbo run test across all 66 test tasks — clean, including the local-dev integration suite.
• @internal/cli on its own: 259 tests pass.
• biome check on the touched sources — clean.
• pnpm check:cli-engine-pin — passes at 0.3.0.

CI will be red until @prisma/cli-engine@0.3.0 publishes (it comes from prisma/prisma-cli#233). pnpm install cannot resolve 0.3.0 from the registry, so it fails before any job runs, and pnpm-lock.yaml cannot be regenerated in this PR. The lockfile update belongs to the commit that follows the publish — the same shape as the previous engine bumps.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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