feat: deploy to Prisma Compute from create-prisma#34
Open
AmanVarshney01 wants to merge 5 commits intomainfrom
Open
feat: deploy to Prisma Compute from create-prisma#34AmanVarshney01 wants to merge 5 commits intomainfrom
AmanVarshney01 wants to merge 5 commits intomainfrom
Conversation
Summary by CodeRabbit
WalkthroughAdds an optional Prisma Compute deploy phase to Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
PR preview published
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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
📒 Files selected for processing (20)
src/commands/create.tssrc/tasks/deploy-to-compute.tssrc/tasks/setup-prisma.tssrc/telemetry/create.tssrc/templates/render-create-template.tssrc/types.tssrc/utils/package-manager.tstemplates/create/astro/astro.config.mjstemplates/create/astro/astro.config.mjs.hbstemplates/create/astro/package.json.hbstemplates/create/elysia/package.json.hbstemplates/create/elysia/prisma.config.ts.hbstemplates/create/elysia/src/index.ts.hbstemplates/create/hono/package.json.hbstemplates/create/hono/prisma.config.ts.hbstemplates/create/hono/src/index.ts.hbstemplates/create/nest/prisma.config.ts.hbstemplates/create/next/next.config.ts.hbstemplates/create/tanstack-start/package.json.hbstemplates/create/tanstack-start/vite.config.ts
💤 Files with no reviewable changes (2)
- templates/create/astro/astro.config.mjs
- src/utils/package-manager.ts
Comment on lines
+43
to
+54
| async function isAuthenticated(): Promise<boolean> { | ||
| if (process.env.PRISMA_API_TOKEN && process.env.PRISMA_API_TOKEN.trim().length > 0) { | ||
| return true; | ||
| } | ||
|
|
||
| try { | ||
| await execa("compute", ["projects", "list", "--json"], { stdio: "pipe" }); | ||
| return true; | ||
| } catch { | ||
| return false; | ||
| } | ||
| } |
There was a problem hiding this comment.
Don't treat any non-empty PRISMA_API_TOKEN as authenticated.
A stale or mistyped token makes this return true, so the flow skips compute login; the first real authenticated call then fails and deployment setup is abandoned. Verify the token with an authenticated CLI call before short-circuiting.
Suggested fix
async function isAuthenticated(): Promise<boolean> {
- if (process.env.PRISMA_API_TOKEN && process.env.PRISMA_API_TOKEN.trim().length > 0) {
- return true;
- }
-
try {
await execa("compute", ["projects", "list", "--json"], { stdio: "pipe" });
return true;
} catch {
return false;
}
}📝 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
| async function isAuthenticated(): Promise<boolean> { | |
| if (process.env.PRISMA_API_TOKEN && process.env.PRISMA_API_TOKEN.trim().length > 0) { | |
| return true; | |
| } | |
| try { | |
| await execa("compute", ["projects", "list", "--json"], { stdio: "pipe" }); | |
| return true; | |
| } catch { | |
| return false; | |
| } | |
| } | |
| async function isAuthenticated(): Promise<boolean> { | |
| try { | |
| await execa("compute", ["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 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.
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (2)
src/tasks/deploy-to-compute.ts (2)
61-64:⚠️ Potential issue | 🟠 MajorValidate
PRISMA_API_TOKENinstead of trusting its presence.A stale or mistyped token makes this return
true, so the flow skipscompute loginand 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 | 🟠 MajorHonor explicit
--deployas a hard requirement.These
return nullbranches downgrade CLI/auth/project-list/project-creation failures into “skip deploy”, socreate --deploycan still exit successfully without deploying anything. Wheninput.deploy === true, surface an error here instead of falling back tonull.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
📒 Files selected for processing (2)
src/commands/create.tssrc/tasks/deploy-to-compute.ts
There was a problem hiding this comment.
♻️ Duplicate comments (5)
src/tasks/deploy-to-compute.ts (5)
207-213:⚠️ Potential issue | 🟠 MajorVerify
tanstack-startis included inCOMPUTE_DEPLOYABLE_TEMPLATES.The guard at line 207 bails out if the template isn't compute-deployable. Per the PR objectives,
tanstack-startis one of the compute-ready templates, but it may not be in theCOMPUTE_DEPLOYABLE_TEMPLATESset insrc/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 | 🟠 MajorUse
reject: falseto capture structured deployment errors from the CLI.
execa()rejects on non-zero exit codes by default, causing the outercatchblock to intercept the error before the JSON parser can extract the machine-readable error message from the CLI's structured response. Usingreject: falseallows 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 | 🟠 MajorHonor explicit
--deployas a hard requirement.When
input.deploy === true, these prerequisite/auth/project-list failures all returnnull, 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 | 🟠 MajorDon't treat any non-empty
PRISMA_API_TOKENas authenticated.A stale or invalid token causes this function to return
true, skippingcompute 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 | 🟡 MinorPopulate actual URLs, not bare endpoint domains.
serviceUrlandversionUrlare set toserviceEndpointDomain/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
📒 Files selected for processing (1)
src/tasks/deploy-to-compute.ts
There was a problem hiding this comment.
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
📒 Files selected for processing (8)
src/commands/create.tssrc/tasks/deploy-to-compute.tssrc/tasks/setup-prisma.tssrc/templates/shared.tssrc/utils/runtime.tstemplates/create/elysia/prisma.config.ts.hbstemplates/create/hono/prisma.config.ts.hbstemplates/create/nest/prisma.config.ts.hbs
| migrateSpinner.stop("Initial migration applied."); | ||
| didMigrate = true; | ||
| } catch (error) { | ||
| migrateSpinner.error(`Migration failed${error instanceof Error ? `: ${error.message}` : "."}`); |
There was a problem hiding this comment.
🧩 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:
- 1: https://www.npmjs.com/package/@clack/prompts
- 2: fix(@clack/prompts): handle spinner.stop call when spinner.start was not called bombshell-dev/clack#242
- 3: https://tessl.io/registry/tessl/npm-clack--prompts/files/docs/progress-indicators.md
- 4: https://bomb.sh/docs/clack/packages/prompts/
- 5: bombshell-dev/clack@0b852e1
- 6: https://bomb.sh/docs/clack/packages/prompts
🏁 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.tsRepository: prisma/create-prisma
Length of output: 46
🏁 Script executed:
rg "\.error\(" src/tasks/setup-prisma.ts -A 1 -B 1Repository: prisma/create-prisma
Length of output: 325
🏁 Script executed:
rg "Spinner|spinner" src/tasks/setup-prisma.ts | head -20Repository: 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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
create-prismafor the compute-deployable templates (hono, elysia, next, astro, nuxt, tanstack-start).compute deploy --project … --service-name … --region …succeeds with no extra flags or manual config edits.Template changes
hono / elysia: default port3000 → 8080to match compute's default http-port; always include"main": "src/index.ts"socompute deploycan auto-detect the entrypoint.hono / elysia / nest:prisma.config.tsalways importsdotenv/config(except for deno, which uses--env-file). Fix for bun wherebunx prisma generatedoesn't inherit auto-loaded env andenv(\"DATABASE_URL\")was failing.next:output: \"standalone\"is unconditional.astro:@astrojs/node+output: \"server\"+adapter: node({ mode: \"standalone\" })are unconditional; addedserver: { host: true }so the node adapter binds0.0.0.0instead of localhost.tanstack-start: bumped to@tanstack/react-start ^1.167.42,vite ^8.0.8,@vitejs/plugin-react ^6.0.0; addednitro ^3.0.260415-betaandnitro()tovite.config.ts; added\"start\": \"node .output/server/index.mjs\"; removed unused@tanstack/router-pluginandvite-tsconfig-paths(using built-inresolve.tsconfigPaths).Test plan
create-prisma create --template hono --prisma-postgres --migrate-and-seed --no-deploythencompute deploy→ 200,/usersreturns seeded rows.elysia,next,astro,nuxt,tanstack-start.