Skip to content

feat: deploy to Prisma Compute from create-prisma#34

Open
AmanVarshney01 wants to merge 9 commits into
mainfrom
feat/compute-deploy-integration
Open

feat: deploy to Prisma Compute from create-prisma#34
AmanVarshney01 wants to merge 9 commits into
mainfrom
feat/compute-deploy-integration

Conversation

@AmanVarshney01
Copy link
Copy Markdown
Member

@AmanVarshney01 AmanVarshney01 commented Apr 23, 2026

Summary

  • Adds an optional "Deploy to Prisma Compute" step at the end of create-prisma for templates supported by the new Prisma CLI deploy flow.
  • Uses @prisma/cli@dev instead of the old @prisma/compute-cli: auth login, project list, and app deploy.
  • Passes DATABASE_URL to deploy only when it came from Prisma Postgres provisioning or explicit user input, not from the local placeholder default.

Deploy flow

  • Reuses an existing Prisma project or lets app deploy --create-project create/link a new one from the generated app directory.
  • Prompts for an App name, then runs prisma app deploy --json --yes --app ... --framework ....
  • Removes region selection because the new app deploy command does not expose a region flag.

Supported deploy templates

  • hono -> --framework hono --http-port 8080
  • elysia -> --framework bun --http-port 8080
  • next -> --framework nextjs
  • tanstack-start -> --framework tanstack-start

Template changes

  • hono / elysia: default port 3000 -> 8080; include "main": "src/index.ts" for deploy entrypoint detection.
  • hono / elysia / nest: prisma.config.ts imports dotenv/config except for deno.
  • next: output: "standalone" is unconditional.
  • astro: node adapter/server output stays scaffold-ready, but automatic Compute deploy is disabled until prisma app deploy supports Astro.
  • tanstack-start: updated runtime deps/config for the current TanStack Start + Nitro path.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 23, 2026

Review Change Stack

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

Adds an optional Prisma Compute deploy phase to create (collect + execute), implements a deploy-to-compute task, makes Prisma setup return detailed results and optionally run migrate+seed, propagates a compute scaffold flag to templates, and adjusts types and templates for server/compute targets.

Changes

Create + Compute Deploy

Layer / File(s) Summary
Types & feature flags
src/types.ts
Adds migrateAndSeed?: boolean and deploy?: boolean, defines COMPUTE_DEPLOYABLE_TEMPLATES and isComputeDeployableTemplate(...) used for compute eligibility.
Compute deploy task implementation
src/tasks/deploy-to-compute.ts
New task file: exports ComputeDeployContext/ComputeDeployResult, collectComputeDeployContext, and executeComputeDeployContext. Implements CLI availability/auth checks, interactive project/app prompts, secret-redaction helpers, JSON parsing of Prisma CLI output, and structured success/cancel/failure returns.
Create command orchestration
src/commands/create.ts
Adds imports and computeDeployContext to prompt context, collects compute context during create (abort on cancel), forwards compute to scaffolding, captures full prismaResult (including databaseUrl/warnings/nextSteps), optionally writes env and runs compute deploy, and incorporates compute/prisma info into outro.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.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 'feat: deploy to Prisma Compute from create-prisma' accurately and concisely summarizes the main feature being added—enabling deployment to Prisma Compute from the create-prisma flow for supported templates.
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.
Description check ✅ Passed The pull request description directly relates to the changeset, providing clear context about adding Prisma Compute deployment functionality, supported templates, and specific template modifications.

✏️ 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 feat/compute-deploy-integration
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch feat/compute-deploy-integration

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Apr 23, 2026

PR preview published

  • Version: 0.4.2-pr.34.109.1
  • Tag: pr34
  • Run with Bun: bunx create-prisma@pr34
  • Run with npm: npx create-prisma@pr34
  • Run with Yarn: yarn dlx create-prisma@pr34
  • Run with pnpm: pnpm dlx create-prisma@pr34
  • Run with Deno: deno run -A npm:create-prisma@pr34
  • Workflow run: https://github.com/prisma/create-prisma/actions/runs/26742189127

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 7

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/commands/create.ts`:
- Around line 430-452: The compute-deploy call using executeComputeDeployContext
inside the context.computeDeployContext block can throw and currently isn't
caught, causing the outer catch to mark failures as "unknown"; wrap the await
executeComputeDeployContext(...) call in a try/catch around the block that
assigns deployResult, and on catch return an error result with stage set to
"compute_deploy" and the caught error as the error payload (keep the existing
handling for result.ok/result.cancelled/result.error for non-throwing returns).
Ensure you reference the same variables (executeComputeDeployContext,
deployResult, context.computeDeployContext, envVars) so the change is localized
to that block.

In `@src/tasks/deploy-to-compute.ts`:
- Around line 124-148: The current early returns (return null) in
ensureComputeOnPath check, authentication block (isAuthenticated + execa login)
and projects fetch (fetchProjects) hide failures and make an explicit deploy
request (input.deploy === true) indistinguishable from a skipped deploy; update
those failure paths to surface a hard failure when input.deploy === true by
throwing a descriptive Error (or process.exit with non-zero) instead of
returning null when input.deploy is true—specifically change the failure branch
in ensureComputeOnPath, the catch after execa("compute", ["login"]) in the
isAuthenticated block, and the catch around fetchProjects to check input.deploy
and throw/exit with a message like "deploy requested but failed to
<check|authenticate|list projects>" otherwise keep returning null for non-deploy
runs.
- Around line 43-54: The isAuthenticated function currently short-circuits to
true if process.env.PRISMA_API_TOKEN is non-empty; instead verify that token by
performing an authenticated CLI call (the same execa("compute", ["projects",
"list", "--json"], ...)) using the environment token—i.e., when PRISMA_API_TOKEN
is set and non-empty, call execa with env extended to include PRISMA_API_TOKEN
and only return true if that call succeeds; if the call fails (throws), treat as
unauthenticated and return false. Ensure you still handle the case where the env
var is absent by attempting the CLI call without injecting the token, and keep
the try/catch around execa to return false on any failure.
- Around line 258-291: The execa call in deployToCompute currently throws on
non-zero exit codes so the outer catch prevents parsing the CLI's structured
JSON; update the execa invocation (the call assigning const { stdout } = await
execa("compute", args, { ... })) to include reject: false in its options so the
process doesn't throw and the existing JSON parse of stdout (the parsed variable
and subsequent !parsed.ok branch) can extract machine-readable errors; keep the
inner parse try/catch and the deploySpinner.error handling as-is to surface the
CLI error message when parsed.ok is false.

In `@src/tasks/setup-prisma.ts`:
- Around line 765-839: The migrateAndSeedIfRequested function runs Prisma CLI
with cwd: projectDir which breaks monorepo templates where prisma files live in
a nested package; update the migration and seed invocations to use the resolved
Prisma project directory (e.g. use context.prismaProjectDir or the existing
resolved prisma directory value if present) instead of projectDir when calling
execa for migrateInvocation and seedInvocation so the commands run from the
actual Prisma config/schema/seed location; modify the two execa calls inside
migrateAndSeedIfRequested to use that resolved directory and fall back to
projectDir if the resolved value is absent.
- Around line 757-762: The returned payload currently only returns
provisionResult.databaseUrl but finalizePrismaFiles() may persist a usable
DATABASE_URL when provisionResult.databaseUrl is undefined; change the return to
include the effective DATABASE_URL (e.g., compute effectiveDatabaseUrl =
provisionResult.databaseUrl ?? the database URL returned/persisted by
finalizePrismaFiles()) and return that effective value in the response object so
create.ts receives the actual usable DATABASE_URL; reference
provisionResult.databaseUrl, finalizePrismaFiles(), and the function that
returns the object to locate where to replace the value.

In `@templates/create/elysia/prisma.config.ts.hbs`:
- Around line 1-3: Extract the inline runtime check from the template into a
reusable helper: add a function requiresPrismaDotenvConfigImport(packageManager)
in src/utils/runtime.ts that returns packageManager !== "deno", register it as a
Handlebars helper named "requiresPrismaDotenvConfigImport" in
src/templates/shared.ts via Handlebars.registerHelper, and update the template
(templates/create/elysia/prisma.config.ts.hbs) to use the helper instead of the
inline {{`#unless` (eq packageManager "deno")}} so all Prisma config templates
call the centralized helper.
🪄 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: ee4a9357-4305-408c-9dce-11c0e4e4850b

📥 Commits

Reviewing files that changed from the base of the PR and between 37d3e83 and 3d1087a.

📒 Files selected for processing (20)
  • src/commands/create.ts
  • src/tasks/deploy-to-compute.ts
  • src/tasks/setup-prisma.ts
  • src/telemetry/create.ts
  • src/templates/render-create-template.ts
  • src/types.ts
  • src/utils/package-manager.ts
  • templates/create/astro/astro.config.mjs
  • templates/create/astro/astro.config.mjs.hbs
  • templates/create/astro/package.json.hbs
  • templates/create/elysia/package.json.hbs
  • templates/create/elysia/prisma.config.ts.hbs
  • templates/create/elysia/src/index.ts.hbs
  • templates/create/hono/package.json.hbs
  • templates/create/hono/prisma.config.ts.hbs
  • templates/create/hono/src/index.ts.hbs
  • templates/create/nest/prisma.config.ts.hbs
  • templates/create/next/next.config.ts.hbs
  • templates/create/tanstack-start/package.json.hbs
  • templates/create/tanstack-start/vite.config.ts
💤 Files with no reviewable changes (2)
  • templates/create/astro/astro.config.mjs
  • src/utils/package-manager.ts

Comment thread src/commands/create.ts
Comment thread src/tasks/deploy-to-compute.ts Outdated
Comment thread src/tasks/deploy-to-compute.ts Outdated
Comment thread src/tasks/deploy-to-compute.ts Outdated
Comment thread src/tasks/setup-prisma.ts
Comment thread src/tasks/setup-prisma.ts
Comment thread templates/create/elysia/prisma.config.ts.hbs Outdated
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

♻️ Duplicate comments (2)
src/tasks/deploy-to-compute.ts (2)

61-64: ⚠️ Potential issue | 🟠 Major

Validate PRISMA_API_TOKEN instead of trusting its presence.

A stale or mistyped token makes this return true, so the flow skips compute login and only fails later during project fetch/deploy. Let the authenticated CLI call prove the token works.

Suggested fix
 async function isAuthenticated(packageManager: PackageManager): Promise<boolean> {
-  if (process.env.PRISMA_API_TOKEN && process.env.PRISMA_API_TOKEN.trim().length > 0) {
-    return true;
-  }
-
   try {
     await runComputeCli(packageManager, ["projects", "list", "--json"], { stdio: "pipe" });
     return true;
   } catch {
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/deploy-to-compute.ts` around lines 61 - 64, The
isAuthenticated(packageManager: PackageManager) function currently returns true
merely because PRISMA_API_TOKEN is present; change it to actually validate the
token by invoking the CLI authentication check instead of trusting the env var.
Replace the short-circuit return with a call that runs the authenticated CLI
command (e.g., the same check used by compute login or a token-verify/
whoami-like command) using PackageManager to execute the CLI and confirm the
token is accepted; only return true when that CLI call succeeds, otherwise
return false so the code will run compute login. Ensure you still read
process.env.PRISMA_API_TOKEN for passing into the CLI but do not treat its
presence as proof of validity.

235-258: ⚠️ Potential issue | 🟠 Major

Honor explicit --deploy as a hard requirement.

These return null branches downgrade CLI/auth/project-list/project-creation failures into “skip deploy”, so create --deploy can still exit successfully without deploying anything. When input.deploy === true, surface an error here instead of falling back to null.

Also applies to: 309-310

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/deploy-to-compute.ts` around lines 235 - 258, The failing branches
in ensureComputeCliAvailable, isAuthenticated/login, and fetchProjects currently
return null which silently skips deploys; when the user explicitly requested a
deploy (check input.deploy === true or options.deploy if that's the flag used in
this file) you must surface an error instead of returning null. Change each
return-null branch inside ensureComputeCliAvailable(...), the catch around
runComputeCli(... "login"), and the catch around fetchProjects(...) to: if
(input.deploy === true) throw a descriptive Error (include the redacted error
details using redactSecrets(error.message) for the message), otherwise keep
returning null for the implicit non-deploy path; apply the same change to the
other similar branches referenced around lines 309-310.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/commands/create.ts`:
- Around line 433-437: The code currently passes envFilePath: ".env" into
executeComputeDeployContext which uploads the entire project .env; instead,
create a deploy-scoped env file that contains only the variables you intend to
expose (e.g., set DATABASE_URL from prismaResult.databaseUrl and any explicitly
whitelisted keys), pass the path of that temporary file as envFilePath to
executeComputeDeployContext, and ensure the temp file is cleaned up after
deploy; keep behavior that envFilePath is undefined when
prismaResult.databaseUrl is not present. Use the existing symbols
executeComputeDeployContext, envFilePath, and prismaResult.databaseUrl to locate
where to generate and supply the scoped env file.

In `@src/tasks/deploy-to-compute.ts`:
- Around line 208-210: The guard using
isComputeDeployableTemplate(options.template) prevents the "tanstack-start"
template from ever reaching the deploy flow; update the predicate/data so
advertised compute-ready templates actually pass this check—specifically add
"tanstack-start" to the COMPUTE_DEPLOYABLE_TEMPLATES list in src/types.ts (or
adjust isComputeDeployableTemplate to include that template), then verify that
isComputeDeployableTemplate(options.template) returns true for "tanstack-start"
so the deploy prompt and execution path in deploy-to-compute.ts is reachable.
- Around line 453-454: The returned serviceUrl and versionUrl are currently set
to plain hostnames (parsed.data.serviceEndpointDomain /
parsed.data.versionEndpointDomain); build full URLs instead by prefixing the
appropriate scheme and "://". For example, set serviceUrl =
(parsed.data.serviceEndpointScheme ?? parsed.data.serviceEndpointProtocol ??
'https') + '://' + parsed.data.serviceEndpointDomain and similarly set
versionUrl = (parsed.data.versionEndpointScheme ??
parsed.data.versionEndpointProtocol ?? 'https') + '://' +
parsed.data.versionEndpointDomain so the contract/outro contains valid URLs;
update the assignments where serviceUrl and versionUrl are created.

---

Duplicate comments:
In `@src/tasks/deploy-to-compute.ts`:
- Around line 61-64: The isAuthenticated(packageManager: PackageManager)
function currently returns true merely because PRISMA_API_TOKEN is present;
change it to actually validate the token by invoking the CLI authentication
check instead of trusting the env var. Replace the short-circuit return with a
call that runs the authenticated CLI command (e.g., the same check used by
compute login or a token-verify/ whoami-like command) using PackageManager to
execute the CLI and confirm the token is accepted; only return true when that
CLI call succeeds, otherwise return false so the code will run compute login.
Ensure you still read process.env.PRISMA_API_TOKEN for passing into the CLI but
do not treat its presence as proof of validity.
- Around line 235-258: The failing branches in ensureComputeCliAvailable,
isAuthenticated/login, and fetchProjects currently return null which silently
skips deploys; when the user explicitly requested a deploy (check input.deploy
=== true or options.deploy if that's the flag used in this file) you must
surface an error instead of returning null. Change each return-null branch
inside ensureComputeCliAvailable(...), the catch around runComputeCli(...
"login"), and the catch around fetchProjects(...) to: if (input.deploy === true)
throw a descriptive Error (include the redacted error details using
redactSecrets(error.message) for the message), otherwise keep returning null for
the implicit non-deploy path; apply the same change to the other similar
branches referenced around lines 309-310.
🪄 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: 04babd4d-6978-43cc-8f31-17e42f91e679

📥 Commits

Reviewing files that changed from the base of the PR and between 3d1087a and caeba1b.

📒 Files selected for processing (2)
  • src/commands/create.ts
  • src/tasks/deploy-to-compute.ts

Comment thread src/commands/create.ts Outdated
Comment thread src/tasks/deploy-to-compute.ts
Comment thread src/tasks/deploy-to-compute.ts Outdated
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

♻️ Duplicate comments (5)
src/tasks/deploy-to-compute.ts (5)

207-213: ⚠️ Potential issue | 🟠 Major

Verify tanstack-start is included in COMPUTE_DEPLOYABLE_TEMPLATES.

The guard at line 207 bails out if the template isn't compute-deployable. Per the PR objectives, tanstack-start is one of the compute-ready templates, but it may not be in the COMPUTE_DEPLOYABLE_TEMPLATES set in src/types.ts.

#!/bin/bash
# Description: Check if tanstack-start is in COMPUTE_DEPLOYABLE_TEMPLATES
rg -n 'COMPUTE_DEPLOYABLE_TEMPLATES' src/types.ts -A 10
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/deploy-to-compute.ts` around lines 207 - 213, The deployment guard
uses isComputeDeployableTemplate which checks membership in the
COMPUTE_DEPLOYABLE_TEMPLATES set, and the PR expects "tanstack-start" to be
considered compute-deployable; update the COMPUTE_DEPLOYABLE_TEMPLATES constant
(referenced by isComputeDeployableTemplate) to include the string
"tanstack-start" so the early-return in deploy-to-compute.ts no longer blocks
that template, then run relevant tests or lint to ensure the change is valid.

434-450: ⚠️ Potential issue | 🟠 Major

Use reject: false to capture structured deployment errors from the CLI.

execa() rejects on non-zero exit codes by default, causing the outer catch block to intercept the error before the JSON parser can extract the machine-readable error message from the CLI's structured response. Using reject: false allows the JSON parsing logic to handle all outcomes and preserves the CLI's error details.

Suggested fix
-    const { stdout } = await runComputeCli(params.context.packageManager, args, {
+    const { stdout, exitCode } = await runComputeCli(params.context.packageManager, args, {
       cwd: params.projectDir,
       stdio: ["ignore", "pipe", "pipe"],
+      reject: false,
     });
 
     const parsed = parseDeployJson(stdout);
     if (!parsed) {
       deploySpinner.error("Deploy failed: could not parse compute deploy output.");
       return { ok: false, cancelled: false, error: new Error("Invalid compute deploy output") };
     }
 
-    if (!parsed.ok) {
+    if (exitCode !== 0 || !parsed.ok) {
       const error = createDeployError(parsed.error.message);
       deploySpinner.error(`Deploy failed: ${error.message}`);
       return { ok: false, cancelled: false, error };
     }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/deploy-to-compute.ts` around lines 434 - 450, The call to
runComputeCli currently lets execa reject on non-zero exits, preventing
parseDeployJson from reading structured CLI errors; update the options passed to
runComputeCli (the third argument in the call) to include reject: false
(alongside cwd and stdio) so the CLI response is returned even on non-zero exit
codes, allowing parseDeployJson to extract machine-readable errors and letting
createDeployError/deploySpinner handle them as intended.

234-258: ⚠️ Potential issue | 🟠 Major

Honor explicit --deploy as a hard requirement.

When input.deploy === true, these prerequisite/auth/project-list failures all return null, making an explicit deploy request indistinguishable from "skip deploy". In non-interactive usage, this leaves the command green without ever deploying. Surface a hard failure when deployment was explicitly requested.

Suggested approach
   if (!(await ensureComputeCliAvailable(options.packageManager))) {
+    if (input.deploy === true) {
+      throw new Error("Deploy requested but Compute CLI is not available");
+    }
     return null;
   }
 
   if (!(await isAuthenticated(options.packageManager))) {
     log.info("Authenticating with Prisma Compute...");
     try {
       await runComputeCli(options.packageManager, ["login"], { stdio: "inherit" });
     } catch (error) {
       log.warn(
         `Compute login was not completed${error instanceof Error ? `: ${redactSecrets(error.message)}` : "."}`,
       );
+      if (input.deploy === true) {
+        throw new Error("Deploy requested but authentication failed");
+      }
       return null;
     }
   }
 
   let projects: ComputeProject[];
   try {
     projects = await fetchProjects(options.packageManager);
   } catch (error) {
     log.warn(
       `Could not list Compute projects${error instanceof Error ? `: ${redactSecrets(error.message)}` : "."}`,
     );
+    if (input.deploy === true) {
+      throw new Error("Deploy requested but could not list Compute projects");
+    }
     return null;
   }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/deploy-to-compute.ts` around lines 234 - 258, When the user
explicitly requested deployment (input.deploy === true) the current
prereq/auth/project-list failures return null and silently skip deployment;
update the catch handlers in deploy-to-compute.ts (around
ensureComputeCliAvailable, isAuthenticated/runComputeCli, and fetchProjects) to
convert those silent returns into hard failures when options.input?.deploy ===
true: inside each catch (or after a failed prerequisite check) check
options.input?.deploy and if true throw an Error (including the redacted
error.message via redactSecrets for context), otherwise keep the existing
log.warn and return null; reference functions/variables
ensureComputeCliAvailable, isAuthenticated, runComputeCli, fetchProjects,
options and redactSecrets to locate and implement the changes.

60-71: ⚠️ Potential issue | 🟠 Major

Don't treat any non-empty PRISMA_API_TOKEN as authenticated.

A stale or invalid token causes this function to return true, skipping compute login. The first real authenticated call then fails, and deployment setup is abandoned. Verify the token with an authenticated CLI call instead of short-circuiting.

Suggested fix
 async function isAuthenticated(packageManager: PackageManager): Promise<boolean> {
-  if (process.env.PRISMA_API_TOKEN && process.env.PRISMA_API_TOKEN.trim().length > 0) {
-    return true;
-  }
-
   try {
     await runComputeCli(packageManager, ["projects", "list", "--json"], { stdio: "pipe" });
     return true;
   } catch {
     return false;
   }
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/deploy-to-compute.ts` around lines 60 - 71, The current
isAuthenticated function incorrectly treats any non-empty PRISMA_API_TOKEN as
valid; change it so that if PRISMA_API_TOKEN exists you still call
runComputeCli(projects list --json) to verify it and only return true on
success. Specifically, update isAuthenticated to invoke
runComputeCli(packageManager, ["projects", "list", "--json"], { env: {
...process.env, PRISMA_API_TOKEN: process.env.PRISMA_API_TOKEN }, stdio: "pipe"
}) (or otherwise ensure the CLI sees the token), return true if that call
succeeds, and return false on any failure; if PRISMA_API_TOKEN is absent fall
back to the same verification path (i.e., always verify via runComputeCli rather
than short-circuiting).

455-462: ⚠️ Potential issue | 🟡 Minor

Populate actual URLs, not bare endpoint domains.

serviceUrl and versionUrl are set to serviceEndpointDomain / versionEndpointDomain, which are hostnames rather than valid URLs. The returned result and any consumer expecting URLs will receive incomplete values. Prefix these with the scheme.

Suggested fix
+    const serviceDomain = parsed.data.serviceEndpointDomain ?? parsed.data.versionEndpointDomain;
     return {
       ok: true,
       result: {
-        serviceUrl: parsed.data.serviceEndpointDomain ?? parsed.data.versionEndpointDomain,
-        versionUrl: parsed.data.versionEndpointDomain,
+        serviceUrl: `https://${serviceDomain}`,
+        versionUrl: `https://${parsed.data.versionEndpointDomain}`,
         serviceId: parsed.data.serviceId,
         versionId: parsed.data.versionId,
         projectId: parsed.data.projectId,
         region: parsed.data.region,
       },
     };

Note: The same fix should be applied to lines 470-477 in the catch block where success is also returned.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/deploy-to-compute.ts` around lines 455 - 462, The returned result
currently uses hostnames (parsed.data.serviceEndpointDomain /
versionEndpointDomain) for serviceUrl and versionUrl; convert these to full URLs
by normalizing and prefixing with the scheme (e.g. ensure strings start with
"http://" or "https://", otherwise prepend "https://") before assigning to
serviceUrl and versionUrl in the result object (use
parsed.data.serviceEndpointDomain and parsed.data.versionEndpointDomain), and
apply the same normalization in the catch block where a success result is also
returned; keep other fields unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@src/tasks/deploy-to-compute.ts`:
- Around line 207-213: The deployment guard uses isComputeDeployableTemplate
which checks membership in the COMPUTE_DEPLOYABLE_TEMPLATES set, and the PR
expects "tanstack-start" to be considered compute-deployable; update the
COMPUTE_DEPLOYABLE_TEMPLATES constant (referenced by
isComputeDeployableTemplate) to include the string "tanstack-start" so the
early-return in deploy-to-compute.ts no longer blocks that template, then run
relevant tests or lint to ensure the change is valid.
- Around line 434-450: The call to runComputeCli currently lets execa reject on
non-zero exits, preventing parseDeployJson from reading structured CLI errors;
update the options passed to runComputeCli (the third argument in the call) to
include reject: false (alongside cwd and stdio) so the CLI response is returned
even on non-zero exit codes, allowing parseDeployJson to extract
machine-readable errors and letting createDeployError/deploySpinner handle them
as intended.
- Around line 234-258: When the user explicitly requested deployment
(input.deploy === true) the current prereq/auth/project-list failures return
null and silently skip deployment; update the catch handlers in
deploy-to-compute.ts (around ensureComputeCliAvailable,
isAuthenticated/runComputeCli, and fetchProjects) to convert those silent
returns into hard failures when options.input?.deploy === true: inside each
catch (or after a failed prerequisite check) check options.input?.deploy and if
true throw an Error (including the redacted error.message via redactSecrets for
context), otherwise keep the existing log.warn and return null; reference
functions/variables ensureComputeCliAvailable, isAuthenticated, runComputeCli,
fetchProjects, options and redactSecrets to locate and implement the changes.
- Around line 60-71: The current isAuthenticated function incorrectly treats any
non-empty PRISMA_API_TOKEN as valid; change it so that if PRISMA_API_TOKEN
exists you still call runComputeCli(projects list --json) to verify it and only
return true on success. Specifically, update isAuthenticated to invoke
runComputeCli(packageManager, ["projects", "list", "--json"], { env: {
...process.env, PRISMA_API_TOKEN: process.env.PRISMA_API_TOKEN }, stdio: "pipe"
}) (or otherwise ensure the CLI sees the token), return true if that call
succeeds, and return false on any failure; if PRISMA_API_TOKEN is absent fall
back to the same verification path (i.e., always verify via runComputeCli rather
than short-circuiting).
- Around line 455-462: The returned result currently uses hostnames
(parsed.data.serviceEndpointDomain / versionEndpointDomain) for serviceUrl and
versionUrl; convert these to full URLs by normalizing and prefixing with the
scheme (e.g. ensure strings start with "http://" or "https://", otherwise
prepend "https://") before assigning to serviceUrl and versionUrl in the result
object (use parsed.data.serviceEndpointDomain and
parsed.data.versionEndpointDomain), and apply the same normalization in the
catch block where a success result is also returned; keep other fields
unchanged.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: b44e19e1-20bd-4737-803e-3b3b041a3eb7

📥 Commits

Reviewing files that changed from the base of the PR and between caeba1b and ee6ed66.

📒 Files selected for processing (1)
  • src/tasks/deploy-to-compute.ts

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/tasks/setup-prisma.ts`:
- Line 819: The spinner error calls use a nonexistent .error() method; update
both migrateSpinner.error(...) and seedSpinner.error(...) to use the
`@clack/prompts` API: call stop(message, 2) instead (e.g.,
migrateSpinner.stop(`Migration failed${error instanceof Error ? `:
${error.message}` : "."}`, 2)) so the spinner stops with error styling and
includes the error message; apply the same change for seedSpinner in the seeding
error handler.
🪄 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: 5d8c89c9-56e0-477e-9d5e-76ecf4054202

📥 Commits

Reviewing files that changed from the base of the PR and between ee6ed66 and 38f13f8.

📒 Files selected for processing (8)
  • src/commands/create.ts
  • src/tasks/deploy-to-compute.ts
  • src/tasks/setup-prisma.ts
  • src/templates/shared.ts
  • src/utils/runtime.ts
  • templates/create/elysia/prisma.config.ts.hbs
  • templates/create/hono/prisma.config.ts.hbs
  • templates/create/nest/prisma.config.ts.hbs

Comment thread src/tasks/setup-prisma.ts Outdated
migrateSpinner.stop("Initial migration applied.");
didMigrate = true;
} catch (error) {
migrateSpinner.error(`Migration failed${error instanceof Error ? `: ${error.message}` : "."}`);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

@clack/prompts spinner error method API

💡 Result:

The @clack/prompts spinner API provides methods for creating loading indicators in CLIs. Common "error" refers to issues with the stop method or error handling. Spinner API: - spinner(options?: SpinnerOptions): SpinnerResult - SpinnerResult methods: start(msg?: string), stop(msg?: string, code?: number), message(msg?: string), isCancelled (readonly) Key options from docs: - indicator: 'dots' | 'timer' - cancelMessage?: string - errorMessage?: string - frames?: string[] - delay?: number - onCancel?: => void | Promise - signal?: AbortSignal stop(msg?: string, code?: number): - msg: completion message - code: 0 (success, green ✓), 1 (cancel, red ×), 2+ (error, red × with styling) Example error handling: const s = spinner; s.start('Operation'); try { // work s.stop('Success', 0); } catch (error) { s.stop(Failed: ${error.message}, 2); // error styling } Known past error: Calling stop before start caused issues, fixed in recent versions (e.g., commit 0b852e10) by returning early if not active: if (!isSpinnerActive) return; No current open spinner errors in GitHub issues. Official docs: https://bomb.sh/docs/clack/packages/prompts/

Citations:


🏁 Script executed:

cat -n src/tasks/setup-prisma.ts | sed -n '810,830p'

Repository: prisma/create-prisma

Length of output: 900


🏁 Script executed:

rg "spinner.*\.error\(" src/tasks/setup-prisma.ts

Repository: prisma/create-prisma

Length of output: 46


🏁 Script executed:

rg "\.error\(" src/tasks/setup-prisma.ts -A 1 -B 1

Repository: prisma/create-prisma

Length of output: 325


🏁 Script executed:

rg "Spinner|spinner" src/tasks/setup-prisma.ts | head -20

Repository: prisma/create-prisma

Length of output: 1221


Replace .error() with .stop() for spinner error handling.

The @clack/prompts spinner does not have an .error() method. Use stop(msg, code) instead, with code 2 for error styling:

Changes needed
- migrateSpinner.error(`Migration failed${error instanceof Error ? `: ${error.message}` : "."}`);
+ migrateSpinner.stop(`Migration failed${error instanceof Error ? `: ${error.message}` : "."}`, 2);

Also apply the same fix to the seedSpinner.error() call in the seeding error handler.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
migrateSpinner.error(`Migration failed${error instanceof Error ? `: ${error.message}` : "."}`);
migrateSpinner.stop(`Migration failed${error instanceof Error ? `: ${error.message}` : "."}`, 2);
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/setup-prisma.ts` at line 819, The spinner error calls use a
nonexistent .error() method; update both migrateSpinner.error(...) and
seedSpinner.error(...) to use the `@clack/prompts` API: call stop(message, 2)
instead (e.g., migrateSpinner.stop(`Migration failed${error instanceof Error ?
`: ${error.message}` : "."}`, 2)) so the spinner stops with error styling and
includes the error message; apply the same change for seedSpinner in the seeding
error handler.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 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 `@src/tasks/deploy-to-compute.ts`:
- Around line 16-23: The code declares CreateTemplate includes "astro" and
"nuxt" but DEPLOY_OPTIONS_BY_TEMPLATE and COMPUTE_DEPLOYABLE_TEMPLATES only list
hono/elysia/next/tanstack-start, causing deployOptions to be undefined and
deploy-to-compute.ts to return null or throw when input.deploy === true; either
add proper entries for "astro" and "nuxt" to DEPLOY_OPTIONS_BY_TEMPLATE (with
appropriate framework/httpPort values) and to COMPUTE_DEPLOYABLE_TEMPLATES or
explicitly remove/mark "astro" and "nuxt" as unsupported where CreateTemplate is
defined and update any docs; update the logic around deployOptions in
deploy-to-compute.ts to handle the chosen approach (e.g., validate
options.template against DEPLOY_OPTIONS_BY_TEMPLATE and throw a clear error or
accept the new entries).
🪄 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: 37336792-bffe-4fda-8f0a-639cca03dbf3

📥 Commits

Reviewing files that changed from the base of the PR and between 38f13f8 and 0b4bfb5.

📒 Files selected for processing (3)
  • src/commands/create.ts
  • src/tasks/deploy-to-compute.ts
  • src/types.ts
💤 Files with no reviewable changes (1)
  • src/types.ts

Comment thread src/tasks/deploy-to-compute.ts
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>

# Conflicts:
#	src/tasks/setup-prisma.ts
#	src/templates/shared.ts
#	src/types.ts
#	templates/create/elysia/prisma.config.ts.hbs
#	templates/create/hono/prisma.config.ts.hbs
#	templates/create/nest/prisma.config.ts.hbs
Signed-off-by: Aman Varshney <amanvarshney.work@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant