feat(cli): support custom compute build config

[AmanVarshney01]

Summary

Adds Prisma CLI support for custom Compute build config. This lets users describe how an app should be built and staged in prisma.compute.ts when the app does not fit one of the first-class framework strategies yet.

Companion PRs:

• prisma/project-compute#97
• prisma/pdp-control-plane#4310

The SDK support has been released, so this PR depends on @prisma/compute-sdk@^0.29.0 and includes the lockfile update.

What changed

• Uses the SDK framework registry for app build --build-type choices instead of duplicating the list in the CLI.
• Adds custom to CLI build result typing.
• Passes prisma.compute.ts build.entrypoint into configured build settings.
• Shows configured build entrypoints in deploy build-settings output.
• Reports the effective deploy entrypoint from configured build settings when no source --entry is used.
• Updates config tests for custom, framework-owned build blocks, and build.entrypoint normalization.
• Updates product docs for build.entrypoint, framework: "custom", and custom artifact builds.

User-facing behavior

A custom artifact can be deployed through prisma.compute.ts by providing:

• framework: "custom"
• build.outputDirectory
• build.entrypoint

build.command is optional. Omit it when the artifact is already built, or set it when the CLI should run a build before staging the artifact.

Example single-app config:

import { defineComputeConfig } from "@prisma/compute-sdk/config";

export default defineComputeConfig({
  app: {
    name: "web",
    framework: "custom",
    httpPort: 3000,
    build: {
      command: "npm run build",
      outputDirectory: "dist",
      entrypoint: "server.js",
    },
  },
});

Users can then run:

prisma-cli app build
prisma-cli app deploy

Example prebuilt artifact config:

import { defineComputeConfig } from "@prisma/compute-sdk/config";

export default defineComputeConfig({
  app: {
    name: "web",
    framework: "custom",
    build: {
      outputDirectory: "dist",
      entrypoint: "server.js",
    },
  },
});

Example monorepo config:

import { defineComputeConfig } from "@prisma/compute-sdk/config";

export default defineComputeConfig({
  apps: {
    frontend: {
      root: "apps/frontend",
      framework: "custom",
      build: {
        command: "npm run build",
        outputDirectory: "dist",
        entrypoint: "server.js",
      },
    },
    api: {
      root: "apps/api",
      framework: "hono",
      entry: "src/index.ts",
    },
  },
});

prisma-cli app build frontend
prisma-cli app deploy frontend

Validation

• pnpm --filter @prisma/cli test
• pnpm --recursive exec tsc --noEmit
• pnpm lint

pnpm lint exits 0 with existing warnings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: fac78692-6f96-41d6-bec2-c13d1265f822

📥 Commits

Reviewing files that changed from the base of the PR and between 92e7c18 and c4d5e82.

📒 Files selected for processing (3)

• docs/product/command-spec.md
• packages/cli/tests/app-controller.test.ts
• packages/cli/tests/compute-config.test.ts

---

Summary by CodeRabbit

• New Features

  • Added support for custom app deployments and expanded framework support in CLI build/deploy workflows.
  • Custom builds can now include an entrypoint alongside output settings, and deployment output now shows that entrypoint when available.

• Bug Fixes

  • Improved deploy result details and console output to better reflect configured build entrypoints.
  • Updated validation messages and error guidance for unsupported build settings.

• Documentation

  • Updated CLI docs and resource model examples to cover the new deployment options and build configuration fields.

Walkthrough

The PR bumps @prisma/compute-sdk to 0.29.0 and extends app build and app deploy to support nestjs and custom framework build types. Build-type constants are now derived from the SDK's FRAMEWORKS list instead of being hardcoded. The build-settings contract adds entrypoint, deploy output can render it, and the controller uses SDK-derived labels and framework metadata. Tests and documentation are updated for custom build normalization, validation, deploy behavior, and the new contract fields.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 10.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately summarizes the main change: adding custom compute build config support in the CLI.
Description check	✅ Passed	The description is clearly related to the changeset and matches the implemented CLI, docs, config, and test updates.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch aman/custom-compute-build-config-cli

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch aman/custom-compute-build-config-cli

---

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

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

packages/cli/tests/compute-config.test.ts (1)

201-233: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Keep a positive test for the newly accepted framework-owned build blocks.

After removing the old nuxt/astro rejection case, this test only proves that custom normalizes correctly. Please keep at least one positive assertion for a framework that used to be rejected, otherwise the contract change to “framework-owned strategies may now carry build settings” is untested.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/cli/tests/compute-config.test.ts` around lines 201 - 233, The
compute-config test now only verifies the custom framework path, so the new
contract for framework-owned build blocks is not covered. Update the test around
compute configuration assertions to include at least one positive case for a
framework that was previously rejected, using the existing compute-config test
setup and config.targets assertions to verify that a framework-owned target can
now carry build settings and normalize them correctly.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/product/command-spec.md`:
- Line 1068: The `framework: "custom"` bullet is too strict and should match the
earlier contract for prebuilt artifacts. Update the documentation near the
`framework: "custom"` requirement so it no longer requires a build command, and
instead states that `build.outputDirectory` and `build.entrypoint` are
sufficient when deploying prebuilt framework output. Use the existing
`framework: "custom"` and `build.entrypoint` references to keep the wording
aligned with the rest of the spec.

In `@packages/cli/src/controllers/app.ts`:
- Around line 849-850: Add controller/integration coverage for the new build
entrypoint flow in runSingleAppDeploy and maybeRenderDeployBuildSettings: add a
test that verifies buildSettingsResolution.settings.entrypoint is used when no
source --entry is provided, and another assertion that the deploy summary
renders the Entrypoint row from that same resolved value. Use the existing app
controller test setup around runSingleAppDeploy/maybeRenderDeployBuildSettings
so the behavior is validated end-to-end, not just through config normalization.

---

Outside diff comments:
In `@packages/cli/tests/compute-config.test.ts`:
- Around line 201-233: The compute-config test now only verifies the custom
framework path, so the new contract for framework-owned build blocks is not
covered. Update the test around compute configuration assertions to include at
least one positive case for a framework that was previously rejected, using the
existing compute-config test setup and config.targets assertions to verify that
a framework-owned target can now carry build settings and normalize them
correctly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: af3cbb94-011a-4319-bd4a-04d2e6fef7af

📥 Commits

Reviewing files that changed from the base of the PR and between ca26012 and 92e7c18.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (10)

• docs/product/command-spec.md
• docs/product/error-conventions.md
• docs/product/resource-model.md
• packages/cli/package.json
• packages/cli/src/controllers/app.ts
• packages/cli/src/lib/app/build-settings.ts
• packages/cli/src/lib/app/build.ts
• packages/cli/src/types/app.ts
• packages/cli/tests/compute-config.test.ts
• pnpm-workspace.yaml

[luanvdw]

Great work @AmanVarshney01!