[wmadden-electric]

// prisma.config.ts
export default definePrismaConfig({
  composer: composer({
    entry: './module.ts',                       // new
    extensions: [prismaCloud(), nodeBuild()],
    state: prismaState(),
  }),
});

$ prisma deploy --stage pr-42          # was: prisma deploy module.ts --stage pr-42
$ prisma dev                           # was: prisma dev module.ts
$ prisma deploy --entry other.ts       # uses other.ts for this one run

The decision: the entry file is set in prisma.config.ts

The entry file is the TypeScript file whose default export is the app's root module. prisma deploy and prisma dev used to take its path as a required argument on every run. Now it is a field of the composer section of prisma.config.ts, and the commands take no argument for it. --entry <path> replaces the config's value for one run.

This follows how the Prisma ORM treats its own inputs. The ORM's section of the same file holds the paths the tool reads, and the commands don't ask for them each time. The entry path is the same kind of thing: an input to the tool, not a fact about the app. Facts about the app, such as its name and its services, stay in code.

How the path resolves

• The config's entry is relative to the folder that holds prisma.config.ts. Prisma's CLI engine resolves path fields in that file the same way, so prisma deploy works from any folder below it.
• --entry is relative to the folder the command runs in, as Prisma's other path flags are.
• With neither, the command fails before doing any work, with CONFIG.ENTRY_MISSING. The message names both ways to supply an entry.
• If the path doesn't load, COMPOSE.ENTRY_UNLOADABLE now says where the path came from (the config file, or --entry) and what it is relative to.

prisma dev reads the entry the same way. It still keeps its local state in the folder it runs in, so run prisma dev, dev url and dev stop from the same folder each time.

What existing users see

After upgrading, prisma deploy module.ts fails with Prisma's own error:

✘ [CLI.INVALID_ARGUMENTS] Too many arguments, expected 0 but encountered "module.ts"

A command that takes no arguments never sees the extra one, so it can't explain where the entry moved. The deploying guide has an upgrade note naming this error and the fix: add entry: './module.ts' to the composer section, or pass --entry module.ts.

Code that calls the operations on @prisma/composer/control (deploy, destroy, dev, log) doesn't change. Their entry input still works and is now optional. When it is given, it replaces the config's value, the same as --entry.

What else changed

• Every example, the website, the CI deploy action, the docs deploy workflow, scripts/composer-destroy.ts (now --entry), the guides, the agent skill and the tests use the config's entry.
• The decision records that set the old command shape are amended: deploy derives the app from the root module (ADR-0003), Composer's config section (ADR-0049) and its commands (ADR-0050). Four older records that show the old command get a one-line note. The error code registry (ADR-0044) lists CONFIG.ENTRY_MISSING.

How we know it works

QA (qa.md) used examples/storage on the real platform:

• prisma deploy with no entry argument deployed the app, and the service stored and returned a file. The same command from a subfolder updated the same app.
• prisma deploy --entry with a second module file deployed that module instead.
• The three error cases each failed as described above, with no change on the platform.
• prisma dev --detach, prisma dev url and prisma dev stop ran from the config's entry and left nothing running.

Every test project was deleted. Typecheck, lint, the CLI tests, the script tests and the local-dev integration tests pass.

Alternatives considered

• Keep the argument and make it optional, with the config as the fallback. It keeps two ways to give the entry on the command line, and a word after prisma deploy could be read as either a file or a subcommand. That matters once prisma deploy list exists.
• Explain the old argument with a Composer error, not the CLI engine's. It isn't possible without declaring an argument the command doesn't use. The engine's error and the upgrade note cover it.

Agent: victoria-52

🤖 Generated with Claude Code

[prisma-gizmo]

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

Open findings: none

Change walkthrough

This PR moves Composer's entry file from a required CLI argument (prisma deploy module.ts) into the composer section of prisma.config.ts, with --entry <path> as a per-run override. The latest delta on top of that adds ADR-0056 dev-server support: under prisma dev, a service whose build adapter declares a dev server runs that command in place of its built artifact, with hot reload and streamed output.

Core types (app-config.ts) — LocalNodeLocation gains an optional command (the argv a dev server runs), logs() gains an addresses filter, and both LocalTargetAttachment and the build-kind NodeDescriptor gain optional serve() capability hooks. All additions are optional, so existing extensions and targets keep working; the new DEV.DEV_SERVER_UNSUPPORTED error covers packages too old to run a dev server.

Pipeline and operations — the CLI pipeline forwards a devServers flag to assembleServices, which lowers dev-server services unassembled instead of assembling them. The dev operation emits three new events (dev-server, dev-server-restarted, dev-server-output), which family/commands/dev.ts renders as <address>: runs `<command>` in <dir> notices, data.devServer marks on front-door endpoints, and [<address>]-prefixed output lines. prisma dev url --json now reports runs: "dev-server" | "artifact" per service, derived from the target's reported command.

Docs, guides and examples — the local-dev domain doc, running-locally.md (a new Dev servers section), getting-started.md, and the agent skill describe the behavior, including the secrets caveat (a .env loaded only by Next.js is too late; load it in prisma.config.ts). The store example was reworked to exercise the feature: the storefront runs next dev, orders and promotions run bun --watch via the node() adapter's dev command, and catalog deliberately keeps the rebuild-and-restart loop; its old fake-server script is deleted and pnpm dev now builds catalog and runs prisma dev.

Tests — coverage spans the command boundary (new dev-servers.test.ts over the operations double), the operation itself (announce/unassembled-lowering/serve/stream happy path, both capability-check failures, failed start with rollback), and the lowering and emulator layers outside this delta's checklist. The docs' claims about error codes and message texts match the source.

[coderabbitai]

Important

• 🔍 Trigger review

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

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 7a269041-4263-4d74-a44b-2efb5471ad66

• Autofix · 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@387

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

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

commit: 9efe5f5

[prisma-gizmo]

New findings: 🔴 2 critical · trace

[prisma-gizmo]

New findings: none · trace

[prisma-gizmo]

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

[prisma-gizmo]

New findings: none · trace

[prisma-gizmo]

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