feat: run Composer under Bun for all repos

[kristof-siket]

Why

Composer's own e2e tests and docs deploys run bun node_modules/.bin/prisma-composer deploy …. Bun is Composer's primary tested runtime; Node is a floor-smoke. The action was previously running Composer under Node (the bin's shebang is #!/usr/bin/env node), which is Composer's least-tested path and is where the TypeScript relative-import problem lives (Node's ESM loader needs exact file paths; Bun resolves TypeScript-style natively and is tsconfig-aware). The Compute runtime itself is Bun. Running the deploy step under Bun:

• puts us on Composer's main path
• makes ./service.ts / ./service.js / extensionless imports all work in CI without any Composer hook
• lets service modules that import Bun APIs deploy

The user's app is still installed and built with its own toolchain — nothing about the app changes.

What changed

• main.mjs: the deploy phase now runs bun <localBin> (local install path) or bunx --bun -p @prisma/composer-cli@<v> prisma-composer (fallback). If bun is not on PATH the action fails early with a message naming the fix (oven-sh/setup-bun@v2). The generated Prisma deploy workflow — produced by pdp-control-plane and opened as a setup PR in the user's repo — adds that step automatically for every project.
• composer.mjs: pure command-selection helper extracted for testability.
• tests/composer.test.mjs: four tests covering both paths and the log labels.
• action.yml: updated composer-version description: npx → bunx.
• README.md: quick-start example now includes oven-sh/setup-bun@v2; added a Requirements section; updated How it works and composer-version table entry.

bunx command

bunx --bun -p @prisma/composer-cli@<version> prisma-composer <args>

--bun forces the spawned bin to run under Bun instead of Node. -p (short for --package) installs the named package if not cached; bunx supports this flag per bunx --help. The local-bin path uses bun <absPath> directly.

Relation to PR #6

PR #6 updates the composer-version default and fallback package reference (stale 0.7.0 default / npx vs bunx). The current PR supersedes the npx → bunx part of that intent; the stale-default concern in #6 can be addressed independently. Check its state before merging — if #6 merges first, no conflict; if this merges first, #6's fallback-package part needs rebasing.

Local verification

With @prisma/composer-cli@0.9.0 installed via bun install in a scratch dir containing module.ts that imports ./service.js (where only service.ts exists):

• bun <localBin> deploy module.ts --stage x → fails at CONFIG.FILE_MISSING (Composer's config lookup runs before module evaluation), confirming the process starts and module resolution is not the stopper.
• node <localBin> deploy module.ts --stage x → same CONFIG.FILE_MISSING result with bun-installed deps, because bun's resolver is tsconfig-aware at install time.

The specific TypeScript relative-import difference (./service.js fails on Node, resolves on Bun) is masked in this test by Composer's config check running first. The full end-to-end proof requires a properly configured project. Additionally: the converge child Composer spawns for the actual deploy still runs under the child's own shebang in 0.9.0 (being fixed in prisma/composer#247). Full end-to-end verification awaits that build (Kristof's side).