feat: enable Prisma Compute deploys for the NestJS template - #46
Conversation
Compute's SDK gained a NestJS build strategy (project-compute #94), so the nest template can now deploy. Add it to COMPUTE_DEPLOYABLE_TEMPLATES and ship a prisma.compute.ts with framework "nestjs" (detected, no entrypoint; the default HTTP port 3000 matches the template's listen port). The compute:deploy script and README Compute sections wire up automatically off the deployable gate.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
Summary by CodeRabbit
WalkthroughThe PR adds comprehensive NestJS support for Prisma Compute deployment. The 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 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}
Enabling nest needs three registries, not one. The first PR only added it to
COMPUTE_DEPLOYABLE_TEMPLATES (which gates the deploy prompt), so the prompt
showed but the deploy was skipped:
- DEPLOY_OPTIONS_BY_TEMPLATE gates the actual deploy. Without a nest entry,
collectComputeDeployContext returned null after the user confirmed, so no
deploy ran and no URL was printed.
- computeConfigTemplates adds @prisma/compute-sdk as a devDependency for the
generated prisma.compute.ts types.
nest is a single-app template, so its deploy entry is {} (no configTarget).
The NestJS deploy strategy compiles and ships dist/, so its build script must emit. The shared runtimeScript helper used `tsc --noEmit` for bun (and `deno check` for deno) because those runtimes execute TypeScript directly — fine for hono/elysia (the SDK bundles their source) but it left nest with no dist/main.js, so deploys failed with "Build failed locally" under bun. Add an `emit` option to runtimeScript; nest opts in so its build compiles to dist on every node-style PM and bun. Deno keeps `deno check` — the Deno nest variant uses Deno APIs and isn't built for the node-based Compute runtime.
1 participant
What
Enables
nestas a Compute-deployable template, now that the SDK has a NestJS build strategy (project-compute #94, shipped in@prisma/compute-sdk@0.28.0and the build-runner).Changes
"nest"toCOMPUTE_DEPLOYABLE_TEMPLATES(src/types.ts).templates/create/nest/prisma.compute.ts.hbswithframework: "nestjs"— framework-detected (noentrypoint), and nohttpPortbecause the SDK's NestJS default (3000) matches the template's listen port (process.env.PORT ?? 3000).Everything else auto-wires off the existing deployable gate: the
compute:deployscript, thecomputerender flag, and the README's{{#if compute}}Compute sections (already present in the nest README) all key offisComputeDeployableTemplate.Verification
tsc --noEmitclean,oxfmt --check+oxlint --deny-warningsclean, build succeeds.nestnon-interactively end-to-end: it emits a correctprisma.compute.ts(framework: "nestjs", project name,env: ".env"), andcompute:deployappears only with--deploy(as expected).emitDecoratorMetadata/experimentalDecoratorsandoutDir: dist, so the build producesdist/main.js— exactly what the SDK's NestJS strategy resolves and traces.