Skip to content

feat: Add Elysia and Nest create templates#31

Merged
AmanVarshney01 merged 10 commits intomainfrom
aman/add-elysia-nest-runtime-cleanup
Apr 7, 2026
Merged

feat: Add Elysia and Nest create templates#31
AmanVarshney01 merged 10 commits intomainfrom
aman/add-elysia-nest-runtime-cleanup

Conversation

@AmanVarshney01
Copy link
Copy Markdown
Member

@AmanVarshney01 AmanVarshney01 commented Mar 31, 2026

What changed

  • adds new elysia and nest create templates
  • updates the Hono template to use the new runtime-aware Prisma config path
  • supports --name . for scaffolding into the current directory
  • centralizes runtime script generation for Hono, Elysia, and Nest
  • cleans up Bun and Deno Prisma/runtime behavior, including Deno --env-file usage
  • ensures dotenv and tsx are added when the generated scaffold actually needs them
  • fixes .env-driven PORT loading for empty-preset Hono/Elysia/Nest and the Turborepo API app

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Mar 31, 2026

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

This pull request adds support for two new project templates (elysia and nest) to the create-prisma tool. It introduces new runtime script generation utilities, extends the dependency system with template-specific dependencies, updates the create command flow, and refactors existing Hono templates to use the new runtime helpers. Both new templates include complete project scaffolding with Prisma integration.

Changes

Cohort / File(s) Summary
Type Definitions
src/types.ts
Added "elysia" and "nest" to the createTemplates tuple; correspondingly updated CreateTemplate union type to include these new template options.
Dependencies Management
src/constants/dependencies.ts, src/tasks/install.ts
Added new exported dependencies (@elysiajs/node, @types/node, tsx) to the version map. Introduced getCreateTemplateDependencies() helper to return template-specific dependency sets. Extended writePrismaDependencies() to conditionally add dotenv based on runtime requirements and project scanning. Added new writeCreateTemplateDependencies() to install template-specific dependencies and append tsx when package scripts reference it.
Package Manager Utilities
src/utils/package-manager.ts
Added requiresDotenvConfigImport() to determine if .env loading is needed per package manager. Added getRuntimeScriptCommand() to generate manager-specific dev/build/start commands (Deno, Bun, or Node-style). Updated Deno Prisma specifier and CLI invocation to include --env-file=.env. Added Bun-specific Prisma script generation and --allow-scripts restrictions for Deno installs.
Create Command Flow
src/commands/create.ts
Extended interactive template selection to include elysia and nest. Updated validateProjectName() to allow "." for scaffolding into the current directory. Refactored collectCreateContext() to validate project name early and call cancel() on failure. Added post-scaffolding writeCreateTemplateDependencies() step in executeCreateContext(). Adjusted Prisma setup preamble handling to omit cd when the target path is ".".
Template Utilities
src/templates/shared.ts
Registered two new Handlebars helpers: requiresDotenvConfigImport(packageManager) and runtimeScript(packageManager, kind, sourceEntrypoint, builtEntrypoint, options). Added hash-parsing utilities to normalize optional Handlebars values and space-delimited lists.
Documentation
README.md
Added examples of scaffolding into the current directory (--name .) and documented support for elysia and nest templates alongside existing templates.
Elysia Template
templates/create/elysia/*
New complete Elysia project template with README, package.json, deno.json, TypeScript config, Prisma setup (schema, migrations, seed), main entry point, Prisma client lib, and conditional dotenv loading and @elysiajs/node dependency based on package manager.
Nest Template
templates/create/nest/*
New complete NestJS (ESM) project template with README, package.json, deno.json, yarn config, TypeScript config, Prisma setup, controllers/services (conditionally for basic schema), main entry point, PrismaService, and Prisma client lib with provider-specific adapters.
Updated Hono Template
templates/create/hono/*
Replaced fixed tsx commands in package.json scripts with dynamic runtimeScript() helper invocations. Removed hardcoded tsx dev dependency (now managed by writeCreateTemplateDependencies()). Converted static prisma.config.ts to Handlebars template to conditionally import dotenv/config and generate package-manager-specific seed commands. Updated Prisma schema generator to include runtime = "bun" condition. Modified seed and index templates to conditionally load dotenv, adjust Prisma import paths for Deno, and use dynamic port selection. Updated README to show manager-specific build/start descriptions.
Other Template Updates
templates/create/tanstack-start/prisma/schema.prisma.hbs, templates/create/turborepo/apps/api/src/index.ts.hbs
Minor cleanup and port selection updates. Tanstack-start schema: removed trailing blank line. Turborepo: added conditional dotenv/config import and dynamic port validation (0–65535 range with 3000 fallback).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~75 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 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 (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely summarizes the main change: adding two new create templates (Elysia and Nest), which is the primary focus of the changeset.
Description check ✅ Passed The description is comprehensive and directly related to the changeset, covering all major changes including new templates, runtime script generation, and various cleanup improvements.

✏️ 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/add-elysia-nest-runtime-cleanup
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch aman/add-elysia-nest-runtime-cleanup

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

@AmanVarshney01 AmanVarshney01 changed the title [codex] Add Elysia and Nest create templates feat: Add Elysia and Nest create templates Mar 31, 2026
@AmanVarshney01 AmanVarshney01 marked this pull request as ready for review March 31, 2026 12:52
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Mar 31, 2026

PR preview published

  • Version: 0.3.2-pr.31.58.1
  • Tag: pr31
  • Run with Bun: bunx create-prisma@pr31
  • Run with npm: npx create-prisma@pr31
  • Run with Yarn: yarn dlx create-prisma@pr31
  • Run with pnpm: pnpm dlx create-prisma@pr31
  • Run with Deno: deno run -A npm:create-prisma@pr31
  • Workflow run: https://github.com/prisma/create-prisma/actions/runs/23946477781

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: 14

Caution

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

⚠️ Outside diff range comments (2)
src/tasks/install.ts (1)

1-267: ⚠️ Potential issue | 🟡 Minor

Pipeline failure: oxfmt formatting check.

The CI pipeline reports an oxfmt formatting failure. Run oxfmt locally to fix formatting issues before merging.

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

In `@src/tasks/install.ts` around lines 1 - 267, CI reports an oxfmt formatting
failure; run oxfmt and commit the fixed formatting. Specifically, run oxfmt on
this file (touchups likely around functions like getPrismaScriptMap,
projectContainsText, addPackageDependency, writePrismaDependencies,
writeCreateTemplateDependencies, and installProjectDependencies), apply the
formatter's changes, verify no logic is altered, then add/commit the formatted
file and push the branch so CI can re-run.
src/templates/shared.ts (1)

1-75: ⚠️ Potential issue | 🟡 Minor

Address the formatting failure from the pipeline.

The CI pipeline reports that oxfmt --check . failed on this file. Run oxfmt (without --check) to fix the formatting issues before merging.

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

In `@src/templates/shared.ts` around lines 1 - 75, The file fails the oxford/oxfmt
formatting check; run the formatter (oxfmt) on this file to apply the required
style changes and commit the updated file; focus on reformatting the exported
helpers and functions (e.g., getOptionalHashString, getOptionalHashStringList,
and the Handlebars.registerHelper blocks like "runtimeScript", "installCommand",
"runScriptCommand", "packageManagerManifestValue", and
"requiresDotenvConfigImport") so the file passes `oxfmt --check .` in CI.
🤖 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/install.ts`:
- Around line 54-82: projectContainsText lacks a recursion depth guard and can
blow the stack on deeply nested trees; add an optional maxDepth (e.g., default
10) and currentDepth parameter to the function signature
(projectContainsText(projectDir: string, text: string, maxDepth = 10,
currentDepth = 0): Promise<boolean>), check at the top if currentDepth >=
maxDepth and return false (or skip recursion), increment currentDepth when
recursing (call projectContainsText(entryPath, text, maxDepth, currentDepth +
1)), and update any call sites to either pass the desired maxDepth or rely on
the default.
- Around line 84-86: scriptUsesBinary currently only checks whitespace-separated
exact tokens so it misses references like ./node_modules/.bin/tsx, /usr/bin/tsx
or path-prefixed tokens; update scriptUsesBinary to treat a token as matching
when the last path segment equals the binary name (handle forward/backslashes
and optional ./ or node_modules/.bin/ prefixes) or when the token equals the
binary, e.g. split the command into tokens and for each token strip quotes and
flags then check if token === binaryName or token.endsWith(pathSep + binaryName)
or token.matches a regex for node_modules/.bin paths; update the function name
scriptUsesBinary accordingly to use this path-aware matching.

In `@src/utils/package-manager.ts`:
- Around line 187-193: The helper currently treats an absent or unknown
packageManager as non-Node (skipping dotenv), which can generate a broken
scaffold; update usesNodeStyleRuntime(packageManager) to validate packageManager
and fail fast for undefined/unknown values (throw a clear Error like "unknown or
missing packageManager") instead of returning false, and have
requiresDotenvConfigImport(packageManager) either call the validated
usesNodeStyleRuntime or itself validate and throw on undefined so the calling
code cannot silently skip adding dotenv/config for Node-style runtimes;
reference the usesNodeStyleRuntime and requiresDotenvConfigImport functions when
making this change.

In `@templates/create/elysia/prisma.config.ts.hbs`:
- Around line 1-15: The two nearly identical Prisma config templates should be
refactored into a Handlebars partial (e.g., prisma.config.partial.hbs) that
contains the shared defineConfig block (including schema, migrations.seed
decision, datasource.url using env("DATABASE_URL"), and optional dotenv import
logic), then replace the duplicated contents in
templates/create/elysia/prisma.config.ts.hbs and
templates/create/hono/prisma.config.ts.hbs with a partial include (for example
{{> prismaConfig packageManager=packageManager
requiresDotenvConfigImport=requiresDotenvConfigImport }}), making sure the
partial accepts the packageManager and requiresDotenvConfigImport parameters so
the seed command branching and optional import remain correct and export default
defineConfig stays in the partial.

In `@templates/create/elysia/README.md.hbs`:
- Around line 20-23: The README template has inconsistent spacing before step 4;
add a blank line before the line that runs the seed command so it matches the
spacing used for steps 2 and 3—specifically insert an empty line above the
backticked `{{runScriptCommand packageManager "db:seed"}}` entry in
templates/create/elysia/README.md.hbs to keep spacing consistent around the
`db:migrate` and `db:seed` steps.

In `@templates/create/elysia/src/index.ts.hbs`:
- Around line 19-26: Wrap the /users route handler (the .get("/users", async ()
=> { ... }) block) so that the prisma.user.findMany call is executed inside a
try/catch; on success return the users, and on failure catch the error, log or
capture it, and return or throw a controlled error response (e.g., an Elysia
HTTP error or a 500 JSON error) instead of leaking unhandled exceptions. Ensure
you reference prisma.user.findMany in the catch path and provide a clear error
message and appropriate status code.

In `@templates/create/elysia/src/lib/prisma.ts.hbs`:
- Around line 5-10: Duplicate conditional blocks import and adapter
instantiation for PrismaPg (used for both "postgresql" and "cockroachdb") should
be consolidated; replace the two separate {{`#if` (eq provider "postgresql")}} and
{{`#if` (eq provider "cockroachdb")}} blocks with a single combined condition that
matches either provider (e.g., an {{`#if` (or (eq provider "postgresql") (eq
provider "cockroachdb"))}} helper or equivalent), and apply the same
consolidation to the adapter instantiation block that constructs PrismaPg so you
only import and instantiate PrismaPg once (symbols: PrismaPg and the adapter
instantiation code).

In `@templates/create/nest/README.md.hbs`:
- Around line 18-24: The numbered list has inconsistent spacing—add a blank line
between the migration line (`{{runScriptCommand packageManager "db:migrate"}}`)
and the seed line (`{{runScriptCommand packageManager "db:seed"}}`) in the
template so step 4 is separated by an empty line just like steps 2 and 3; update
the README.md.hbs content to insert that single blank line.

In `@templates/create/nest/scripts/dev.ts.hbs`:
- Around line 27-33: The startApp function uses a hardcoded "dist/main.js" path
while entryPath is defined as path.join(distDir, "main.js"); update startApp to
use the entryPath constant instead of the literal string so the spawn call
references entryPath (preserving existing options like stdio, shell), and keep
using the existing symbols appProcess, killProcess, spawn, entryPath and distDir
to maintain consistency.
- Around line 1-4: The template templates/create/nest/scripts/dev.ts.hbs
currently generates an empty dev.ts for Deno and Bun because the Handlebars
conditionals for packageManager ("deno" and "bun") aren't excluding file
generation; update the template so the dev.ts.hbs only produces content when
packageManager is neither "deno" nor "bun" (e.g., use a single conditional that
checks (or) or an unless for (eq packageManager "deno") and (eq packageManager
"bun")), or adjust the generator to skip emitting dev.ts entirely for those
package managers; reference the packageManager checks in dev.ts.hbs to locate
and fix the logic.

In `@templates/create/nest/src/lib/prisma.ts.hbs`:
- Around line 6-11: The two conditional import blocks for PrismaPg are
duplicated; consolidate them into a single conditional that checks for either
provider value so PrismaPg is imported once (look for the template helpers using
(eq provider "postgresql") and (eq provider "cockroachdb") and the imported
symbol PrismaPg) — change the template logic to a single conditional that
matches both provider values and imports PrismaPg only once.

In `@templates/create/nest/src/main.ts.hbs`:
- Line 17: The bootstrap invocation currently ignores promise rejections because
it simply calls void bootstrap(); — modify the process entrypoint that calls
bootstrap() so it attaches a .catch(...) handler that logs the error (using the
existing logger or console.error) and calls process.exit with a non-zero code;
locate the bootstrap() call in main/bootstrap entry (symbol: bootstrap) and
replace the bare call with a promise-handling chain that logs the error and
exits deterministically on failure.
- Line 12: The port parsing can produce NaN for malformed env values and must
allow 0 as valid; change the single-line const port = Number(...) ?? 3000 to
first parse into a numeric variable (e.g., parsedPort =
Number(Deno.env.get("PORT") or process.env.PORT)) then set port =
Number.isFinite(parsedPort) ? parsedPort : 3000 so that non-finite values fall
back to 3000 but 0 is preserved; update the expression around the existing port
constant in main.ts.hbs where the port is declared to use this finite-check
logic.

In `@templates/create/nest/src/prisma.service.ts.hbs`:
- Around line 1-10: Update PrismaService to manage Prisma connections via Nest
lifecycle hooks: implement OnModuleInit and OnModuleDestroy (or call
this.enableShutdownHooks in the constructor) and in onModuleInit call await
this.$connect() to force early connection and surface startup errors, and in
onModuleDestroy call await this.$disconnect() for graceful shutdown; reference
the PrismaService class, its constructor using prismaClientOptions, and the
methods onModuleInit/onModuleDestroy or enableShutdownHooks when making the
changes.

---

Outside diff comments:
In `@src/tasks/install.ts`:
- Around line 1-267: CI reports an oxfmt formatting failure; run oxfmt and
commit the fixed formatting. Specifically, run oxfmt on this file (touchups
likely around functions like getPrismaScriptMap, projectContainsText,
addPackageDependency, writePrismaDependencies, writeCreateTemplateDependencies,
and installProjectDependencies), apply the formatter's changes, verify no logic
is altered, then add/commit the formatted file and push the branch so CI can
re-run.

In `@src/templates/shared.ts`:
- Around line 1-75: The file fails the oxford/oxfmt formatting check; run the
formatter (oxfmt) on this file to apply the required style changes and commit
the updated file; focus on reformatting the exported helpers and functions
(e.g., getOptionalHashString, getOptionalHashStringList, and the
Handlebars.registerHelper blocks like "runtimeScript", "installCommand",
"runScriptCommand", "packageManagerManifestValue", and
"requiresDotenvConfigImport") so the file passes `oxfmt --check .` in CI.
🪄 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: 4f9e715b-2c30-4cde-85d5-15a9774e295e

📥 Commits

Reviewing files that changed from the base of the PR and between 6fd2070 and 8db129a.

📒 Files selected for processing (43)
  • README.md
  • src/commands/create.ts
  • src/constants/dependencies.ts
  • src/tasks/install.ts
  • src/templates/shared.ts
  • src/types.ts
  • src/utils/package-manager.ts
  • templates/create/elysia/README.md.hbs
  • templates/create/elysia/deno.json.hbs
  • templates/create/elysia/package.json.hbs
  • templates/create/elysia/prisma.config.ts.hbs
  • templates/create/elysia/prisma/schema.prisma.hbs
  • templates/create/elysia/prisma/seed.ts.hbs
  • templates/create/elysia/src/index.ts.hbs
  • templates/create/elysia/src/lib/prisma.ts.hbs
  • templates/create/elysia/tsconfig.json
  • templates/create/hono/README.md.hbs
  • templates/create/hono/package.json.hbs
  • templates/create/hono/prisma.config.ts
  • templates/create/hono/prisma.config.ts.hbs
  • templates/create/hono/prisma/schema.prisma.hbs
  • templates/create/hono/prisma/seed.ts.hbs
  • templates/create/hono/src/index.ts.hbs
  • templates/create/hono/src/lib/prisma.ts.hbs
  • templates/create/nest/.gitignore
  • templates/create/nest/.yarnrc.yml.hbs
  • templates/create/nest/README.md.hbs
  • templates/create/nest/deno.json.hbs
  • templates/create/nest/package.json.hbs
  • templates/create/nest/prisma.config.ts.hbs
  • templates/create/nest/prisma/schema.prisma.hbs
  • templates/create/nest/prisma/seed.ts.hbs
  • templates/create/nest/scripts/dev.ts.hbs
  • templates/create/nest/src/app.controller.ts.hbs
  • templates/create/nest/src/app.module.ts.hbs
  • templates/create/nest/src/lib/prisma.ts.hbs
  • templates/create/nest/src/main.ts.hbs
  • templates/create/nest/src/prisma.service.ts.hbs
  • templates/create/nest/src/users.controller.ts.hbs
  • templates/create/nest/src/users.service.ts.hbs
  • templates/create/nest/tsconfig.json
  • templates/create/tanstack-start/prisma/schema.prisma.hbs
  • templates/create/turborepo/apps/api/src/index.ts.hbs
💤 Files with no reviewable changes (2)
  • templates/create/tanstack-start/prisma/schema.prisma.hbs
  • templates/create/hono/prisma.config.ts

Comment thread src/tasks/install.ts
Comment thread src/tasks/install.ts Outdated
Comment thread src/utils/package-manager.ts Outdated
Comment thread templates/create/elysia/prisma.config.ts.hbs
Comment thread templates/create/elysia/README.md.hbs
Comment thread templates/create/nest/scripts/dev.ts.hbs Outdated
Comment thread templates/create/nest/src/lib/prisma.ts.hbs
Comment thread templates/create/nest/src/main.ts.hbs Outdated
Comment thread templates/create/nest/src/main.ts.hbs Outdated
Comment thread templates/create/nest/src/prisma.service.ts.hbs
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: 8

♻️ Duplicate comments (2)
templates/create/elysia/src/index.ts.hbs (1)

10-10: ⚠️ Potential issue | 🟡 Minor

Port parsing can produce NaN for invalid env values.

This pattern appears in multiple templates (elysia, hono, nest, turborepo). A malformed PORT environment variable (e.g., "abc") will result in NaN being passed to .listen(...), bypassing the default value.

🔧 Proposed fix
-const port = Number({{`#if` (eq packageManager "deno")}}Deno.env.get("PORT"){{else}}process.env.PORT{{/if}} ?? 3000);
+const rawPort = {{`#if` (eq packageManager "deno")}}Deno.env.get("PORT"){{else}}process.env.PORT{{/if}};
+const parsedPort = Number(rawPort);
+const port = Number.isInteger(parsedPort) && parsedPort > 0 ? parsedPort : 3000;

Apply this fix across all affected templates: elysia, hono, nest, and turborepo.

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

In `@templates/create/elysia/src/index.ts.hbs` at line 10, The port parsing
assigns Number(Deno.env.get("PORT") / process.env.PORT) directly which yields
NaN for invalid values and bypasses the default 3000; update the initialization
of port (the port constant in templates using Deno.env.get("PORT") or
process.env.PORT) to first read the raw env string, parse it with
parseInt/Number, validate with Number.isInteger/!Number.isNaN (or a simple isNaN
check), and fall back to 3000 when parsing fails or the value is invalid so
.listen(...) always receives a valid numeric port; apply the same change across
the elysia, hono, nest, and turborepo templates.
src/tasks/install.ts (1)

54-82: ⚠️ Potential issue | 🟠 Major

Bound and harden the dotenv/config scan before using it on arbitrary directories.

This helper now walks whatever projectDir points at, but it still has no recursion guard and lets readdir / readFile errors abort the whole create flow. With --name ., a deep tree or a single unreadable entry can fail scaffolding even though this scan is only a heuristic. Add a max depth and treat per-entry read errors as “not found”.

💡 Suggested hardening
-async function projectContainsText(projectDir: string, text: string): Promise<boolean> {
-  const entries = await fs.readdir(projectDir, { withFileTypes: true });
+async function projectContainsText(
+  projectDir: string,
+  text: string,
+  maxDepth = 8,
+  currentDepth = 0,
+): Promise<boolean> {
+  if (currentDepth >= maxDepth) {
+    return false;
+  }
+
+  const entries = await fs.readdir(projectDir, { withFileTypes: true }).catch(() => null);
+  if (!entries) {
+    return false;
+  }

   for (const entry of entries) {
@@
     const entryPath = path.join(projectDir, entry.name);

     if (entry.isDirectory()) {
-      if (await projectContainsText(entryPath, text)) {
+      if (await projectContainsText(entryPath, text, maxDepth, currentDepth + 1)) {
         return true;
       }
       continue;
     }
@@
-    const content = await fs.readFile(entryPath, "utf8");
+    const content = await fs.readFile(entryPath, "utf8").catch(() => null);
+    if (content === null) {
+      continue;
+    }
+
     if (content.includes(text)) {
       return true;
     }
   }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/tasks/install.ts` around lines 54 - 82, The projectContainsText helper
currently recursively walks projectDir without depth limits and lets
fs.readdir/fs.readFile errors abort the whole flow; update projectContainsText
to accept (or use a constant) maxDepth and currentDepth parameters, stop
recursing when currentDepth >= maxDepth, and wrap per-entry fs operations
(readdir/readFile/stat if used) in try/catch so any error on a single entry is
treated as “not found” (log.debug or ignore) and the scan continues; keep the
same file-type filter (/\.(c|m)?[jt]sx?$/) and still skip "node_modules" and
".git", and ensure recursive calls pass incremented depth to avoid unbounded
traversal.
🤖 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 328-331: writeCreateTemplateDependencies currently only scans
package.json scripts for "tsx" and runs before executePrismaSetupContext, so
templates like hono/elysia that reference "tsx" in prisma.config.ts.hbs (seed
runner "tsx prisma/seed.ts") are missed; fix by either moving the call to
writeCreateTemplateDependencies to after executePrismaSetupContext so the
rendered prisma.config.ts contains the seed command, or enhance
writeCreateTemplateDependencies to also scan template files (e.g.,
prisma.config.ts.hbs) and the rendered prisma config for "tsx" references before
deciding to add the dependency; update the function call/sites where
writeCreateTemplateDependencies is invoked and adjust its detection logic to
look for "tsx prisma/seed" in template/rendered config content.

In `@src/utils/package-manager.ts`:
- Around line 32-34: The normalizeVersion function is removing leading range
operators (e.g., ^, ~) and causing Prisma Deno specifiers to become exact
versions; either preserve the range operators by removing calls to
normalizeVersion where Prisma versions are used (locations referencing
dependencyVersionMap.prisma and dependencyVersionMap["@prisma/client"] in code
that builds Deno specifiers) or change dependencyVersionMap to use exact
versions without ^/~; specifically, locate normalizeVersion and all call sites
that feed Deno specifiers (functions that build Prisma/@prisma/client
specifiers) and either stop calling normalizeVersion there or update
dependencyVersionMap entries to exact numbers so the manifest and generated Deno
specifiers stay consistent.

In `@templates/create/elysia/src/lib/prisma.ts.hbs`:
- Line 4: Update the import of PrismaClient in the Prisma helper templates to
include a Deno-specific ".ts" suffix when packageManager === "deno";
specifically change the import statement that currently reads like import {
PrismaClient } from "../generated/prisma/client"; in
templates/create/elysia/src/lib/prisma.ts.hbs and the equivalent in
templates/create/nest/src/lib/prisma.ts.hbs to use the conditional suffix
pattern used in templates/create/nest/prisma/seed.ts.hbs (i.e., append {{`#if` (eq
packageManager "deno")}}.ts{{/if}}), so the generated code imports
"../generated/prisma/client.ts" for Deno and "../generated/prisma/client"
otherwise.

In `@templates/create/hono/src/index.ts.hbs`:
- Line 31: The current port assignment (const port = Number(... ) ?? 3000) can
produce NaN for malformed PORT values; change the initialization of port so you
first read the raw string (using Deno.env.get("PORT") or process.env.PORT),
convert with Number or parseInt, then validate (e.g., Number.isFinite(result) or
!Number.isNaN(result)) and fallback to 3000 when invalid; update the const port
expression in this template (the variable named port) to perform this check so
serve() always receives a valid numeric port.

In `@templates/create/hono/src/lib/prisma.ts.hbs`:
- Around line 22-24: The databaseUrl assignment uses the nullish coalescing
operator (??) which lets empty strings through; update the expression that reads
Deno.env.get("DATABASE_URL") / process.env.DATABASE_URL so it trims and falls
back when the value is empty or whitespace (e.g., call .trim() on the env value
when present and use || "file:./dev.db" as the fallback). Ensure you safely
handle null/undefined before calling .trim() (check the raw env value, then
apply .trim() || "file:./dev.db") so the variable databaseUrl never becomes an
empty string.

In `@templates/create/nest/scripts/dev.ts.hbs`:
- Around line 46-55: waitForBuildOutput currently resolves both when the build
appears and when shuttingDown flips true, letting startup proceed after an early
shutdown; change waitForBuildOutput to distinguish the two by rejecting
(throwing) or returning a failure flag when it exits because shuttingDown is
true (instead of resolving), and update the caller code that currently assumes
success (the block that installs the watcher and starts dist/main.js) to treat
this rejection/false return as failure and abort startup so the watcher/start
sequence does not run after a shutdown race. Use the existing symbols
waitForBuildOutput, shuttingDown, and entryPath to locate and implement the
change.
- Around line 27-43: The restart path currently calls killProcess(appProcess)
and immediately spawns a new process in startApp, which can cause EADDRINUSE
because the old Nest process may not have exited; change
startApp/scheduleRestart so that after calling killProcess(appProcess) you wait
for the existing appProcess to fully exit (listen for its 'exit'/'close' event
or await a promise returned by killProcess) before calling spawn("tsx",
["dist/main.js"]), and only clear/reset restartTimer as needed; use the existing
symbols appProcess, killProcess, startApp, scheduleRestart, restartTimer to
locate where to attach the wait and to conditionally spawn only after the
previous process is confirmed terminated.

In `@templates/create/nest/tsconfig.json`:
- Around line 4-6: The tsconfig uses "moduleResolution": "Bundler" which doesn't
match running compiled output directly under Node; update the tsconfig.json to
use a Node-aligned resolution (e.g., set "moduleResolution" to "NodeNext") so
TypeScript resolves ESM/Node-style imports the same way runtime (Node/tsx) will;
adjust alongside existing settings like "module": "ESNext" and
"verbatimModuleSyntax" to ensure consistent Node ESM semantics.

---

Duplicate comments:
In `@src/tasks/install.ts`:
- Around line 54-82: The projectContainsText helper currently recursively walks
projectDir without depth limits and lets fs.readdir/fs.readFile errors abort the
whole flow; update projectContainsText to accept (or use a constant) maxDepth
and currentDepth parameters, stop recursing when currentDepth >= maxDepth, and
wrap per-entry fs operations (readdir/readFile/stat if used) in try/catch so any
error on a single entry is treated as “not found” (log.debug or ignore) and the
scan continues; keep the same file-type filter (/\.(c|m)?[jt]sx?$/) and still
skip "node_modules" and ".git", and ensure recursive calls pass incremented
depth to avoid unbounded traversal.

In `@templates/create/elysia/src/index.ts.hbs`:
- Line 10: The port parsing assigns Number(Deno.env.get("PORT") /
process.env.PORT) directly which yields NaN for invalid values and bypasses the
default 3000; update the initialization of port (the port constant in templates
using Deno.env.get("PORT") or process.env.PORT) to first read the raw env
string, parse it with parseInt/Number, validate with
Number.isInteger/!Number.isNaN (or a simple isNaN check), and fall back to 3000
when parsing fails or the value is invalid so .listen(...) always receives a
valid numeric port; apply the same change across the elysia, hono, nest, and
turborepo templates.
🪄 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: 56657672-44b1-45b1-816f-0dc4f72520af

📥 Commits

Reviewing files that changed from the base of the PR and between 6fd2070 and 077734e.

📒 Files selected for processing (43)
  • README.md
  • src/commands/create.ts
  • src/constants/dependencies.ts
  • src/tasks/install.ts
  • src/templates/shared.ts
  • src/types.ts
  • src/utils/package-manager.ts
  • templates/create/elysia/README.md.hbs
  • templates/create/elysia/deno.json.hbs
  • templates/create/elysia/package.json.hbs
  • templates/create/elysia/prisma.config.ts.hbs
  • templates/create/elysia/prisma/schema.prisma.hbs
  • templates/create/elysia/prisma/seed.ts.hbs
  • templates/create/elysia/src/index.ts.hbs
  • templates/create/elysia/src/lib/prisma.ts.hbs
  • templates/create/elysia/tsconfig.json
  • templates/create/hono/README.md.hbs
  • templates/create/hono/package.json.hbs
  • templates/create/hono/prisma.config.ts
  • templates/create/hono/prisma.config.ts.hbs
  • templates/create/hono/prisma/schema.prisma.hbs
  • templates/create/hono/prisma/seed.ts.hbs
  • templates/create/hono/src/index.ts.hbs
  • templates/create/hono/src/lib/prisma.ts.hbs
  • templates/create/nest/.gitignore
  • templates/create/nest/.yarnrc.yml.hbs
  • templates/create/nest/README.md.hbs
  • templates/create/nest/deno.json.hbs
  • templates/create/nest/package.json.hbs
  • templates/create/nest/prisma.config.ts.hbs
  • templates/create/nest/prisma/schema.prisma.hbs
  • templates/create/nest/prisma/seed.ts.hbs
  • templates/create/nest/scripts/dev.ts.hbs
  • templates/create/nest/src/app.controller.ts.hbs
  • templates/create/nest/src/app.module.ts.hbs
  • templates/create/nest/src/lib/prisma.ts.hbs
  • templates/create/nest/src/main.ts.hbs
  • templates/create/nest/src/prisma.service.ts.hbs
  • templates/create/nest/src/users.controller.ts.hbs
  • templates/create/nest/src/users.service.ts.hbs
  • templates/create/nest/tsconfig.json
  • templates/create/tanstack-start/prisma/schema.prisma.hbs
  • templates/create/turborepo/apps/api/src/index.ts.hbs
💤 Files with no reviewable changes (2)
  • templates/create/tanstack-start/prisma/schema.prisma.hbs
  • templates/create/hono/prisma.config.ts

Comment thread src/commands/create.ts
Comment thread src/utils/package-manager.ts Outdated
Comment thread templates/create/elysia/src/lib/prisma.ts.hbs Outdated
Comment thread templates/create/hono/src/index.ts.hbs Outdated
Comment thread templates/create/hono/src/lib/prisma.ts.hbs Outdated
Comment thread templates/create/nest/scripts/dev.ts.hbs Outdated
Comment thread templates/create/nest/scripts/dev.ts.hbs Outdated
Comment thread templates/create/nest/tsconfig.json
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: 6

♻️ Duplicate comments (6)
templates/create/nest/src/main.ts.hbs (1)

19-19: ⚠️ Potential issue | 🟠 Major

Handle bootstrap rejections at the entrypoint.

Line 19 discards the promise returned by bootstrap(), so startup failures from NestFactory.create() or app.listen() are not handled here. Attach a .catch(...) and exit non-zero.

Suggested fix
-void bootstrap();
+bootstrap().catch((error) => {
+  console.error("Failed to start server", error);
+  {{`#if` (eq packageManager "deno")}}
+  Deno.exit(1);
+  {{else}}
+  process.exit(1);
+  {{/if}}
+});
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@templates/create/nest/src/main.ts.hbs` at line 19, The bootstrap() call at
the entrypoint is currently unhandled; update the invocation of the bootstrap
function so any rejection from NestFactory.create() or app.listen() is
caught—call bootstrap().catch(err => { console.error('Bootstrap failed', err);
process.exit(1); }) — reference the bootstrap function and ensure the catch logs
the error and calls process.exit(1) to exit non‑zero on failure.
templates/create/elysia/README.md.hbs (1)

20-24: ⚠️ Potential issue | 🟡 Minor

Minor formatting inconsistency: missing blank line before step 4.

Steps 2 and 3 have blank lines before them, but step 4 does not. This creates inconsistent visual spacing in the generated README.

📝 Proposed fix
 `{{runScriptCommand packageManager "db:migrate"}}`
+
 4. Seed the database:
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@templates/create/elysia/README.md.hbs` around lines 20 - 24, The README
template has inconsistent spacing: add a blank line before the "4. Seed the
database:" step in templates/create/elysia/README.md.hbs so it matches the
blank-line formatting used for steps 2 and 3; update the block that renders
`{{runScriptCommand packageManager "db:migrate"}}`/`{{runScriptCommand
packageManager "db:seed"}}` to insert an empty line between the migrate command
line and the "4. Seed the database:" line so the generated README has consistent
visual spacing.
src/utils/package-manager.ts (1)

182-188: ⚠️ Potential issue | 🟠 Major

undefined packageManager silently treated as Bun/Deno.

When packageManager is undefined, requiresDotenvConfigImport returns false, which could silently skip adding the dotenv/config import for Node-style runtimes. Consider failing fast or logging a warning.

♻️ Proposed fix
-function usesNodeStyleRuntime(packageManager: PackageManager | undefined): boolean {
-  return packageManager !== undefined && packageManager !== "bun" && packageManager !== "deno";
+function usesNodeStyleRuntime(packageManager: PackageManager): boolean {
+  return packageManager !== "bun" && packageManager !== "deno";
 }

-export function requiresDotenvConfigImport(packageManager: PackageManager | undefined): boolean {
+export function requiresDotenvConfigImport(packageManager: PackageManager): boolean {
   return usesNodeStyleRuntime(packageManager);
 }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/utils/package-manager.ts` around lines 182 - 188, The helper
usesNodeStyleRuntime currently treats packageManager === undefined as false,
which silently skips dotenv imports; update the logic to fail fast when
packageManager is undefined by adding an explicit check in
requiresDotenvConfigImport (or at the top of usesNodeStyleRuntime) that throws a
clear error or logs a warning and returns a safe default; specifically locate
the functions usesNodeStyleRuntime and requiresDotenvConfigImport and either: 1)
throw a descriptive error when packageManager is undefined, or 2) log a warning
and assume a Node-style manager (e.g., npm) before performing the existing
bun/deno checks so behavior is explicit.
templates/create/nest/src/lib/prisma.ts.hbs (1)

6-11: 🧹 Nitpick | 🔵 Trivial

Same consolidation opportunity as the Elysia template.

The PostgreSQL and CockroachDB blocks are duplicated here as well.

Also applies to: 32-41

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

In `@templates/create/nest/src/lib/prisma.ts.hbs` around lines 6 - 11, Duplicate
conditional import blocks for PostgreSQL and CockroachDB should be consolidated:
replace the two separate {{`#if` (eq provider "postgresql")}} ... {{/if}} and
{{`#if` (eq provider "cockroachdb")}} ... {{/if}} import blocks with a single
combined conditional that checks either provider (e.g., {{`#if` (or (eq provider
"postgresql") (eq provider "cockroachdb"))}} import { PrismaPg } from
"@prisma/adapter-pg"; {{/if}}) and apply the same consolidation for the later
duplicate at lines 32-41; remove the redundant block(s) so the import appears
only once when provider is postgresql or cockroachdb.
templates/create/nest/README.md.hbs (1)

18-25: ⚠️ Potential issue | 🟡 Minor

Minor formatting inconsistency in numbered list.

There's a missing blank line before step 4, creating inconsistent spacing compared to steps 2 and 3.

📝 Proposed fix
 3. Run your first migration:

 `{{runScriptCommand packageManager "db:migrate"}}`
+
 4. Seed the database:

 `{{runScriptCommand packageManager "db:seed"}}`
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@templates/create/nest/README.md.hbs` around lines 18 - 25, Add a blank line
before the "4. Seed the database:" list item to match the spacing used between
earlier numbered steps; update the template around the "3. Run your first
migration:" block that contains `{{runScriptCommand packageManager
"db:migrate"}}` so there is a separating blank line before the
`{{runScriptCommand packageManager "db:seed"}}` line for step "4." to keep
consistent formatting.
templates/create/elysia/src/lib/prisma.ts.hbs (1)

5-10: 🧹 Nitpick | 🔵 Trivial

Consider consolidating duplicate PostgreSQL/CockroachDB blocks.

Both PostgreSQL and CockroachDB use identical PrismaPg import and adapter instantiation. While functionally correct, consolidating would reduce template duplication.

♻️ Proposed refactor using an `or` helper

If an or helper is registered (or can be added):

{{`#if` (or (eq provider "postgresql") (eq provider "cockroachdb"))}}
import { PrismaPg } from "@prisma/adapter-pg";
{{/if}}

The same pattern applies to the adapter instantiation blocks.

Also applies to: 31-40

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

In `@templates/create/elysia/src/lib/prisma.ts.hbs` around lines 5 - 10, Duplicate
conditional blocks importing and instantiating PrismaPg for provider values
"postgresql" and "cockroachdb" should be consolidated into a single conditional
to avoid repetition; update both the import and the adapter instantiation
sections in the template so they use a combined condition (e.g., an or helper or
a single check that matches either provider) referencing the provider variable
and the PrismaPg symbol so only one "{{`#if` ...}} import { PrismaPg } from
"@prisma/adapter-pg"; {{/if}}" and one adapter instantiation block remain for
both PostgreSQL and CockroachDB.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@templates/create/elysia/src/index.ts.hbs`:
- Around line 4-5: The template currently always imports and uses the Node
adapter (import { node } from "@elysiajs/node"; new Elysia({ adapter: node() })
and app.listen(port)), which breaks the packageManager === "deno" branch; update
the code so the "@elysiajs/node" import and adapter: node() usage are
conditional (only for non-Deno), and when packageManager === "deno" create the
app with new Elysia() (no node adapter) and start it using Deno.serve({ port },
app.fetch) instead of app.listen(port); ensure the packageManager === "deno"
branch also uses Deno.serve and references app.fetch while the other branch
keeps adapter: node() and .listen(port).
- Around line 6-7: The import for prisma in the template is missing the
Deno-required file extension; update the import inside the {{`#if` (eq
schemaPreset "basic")}} block to reference "./lib/prisma.ts" instead of
"./lib/prisma" so the generated file imports prisma with the .ts suffix (symbol:
prisma, template: templates/create/elysia/src/index.ts.hbs).

In `@templates/create/nest/scripts/dev.ts.hbs`:
- Line 13: The code uses useShell = process.platform === "win32" and spawns
children with shell: useShell, which on Windows causes child.kill() and await
once(previousAppProcess, "exit") to only observe the shell, leaving grandchild
processes (tsx/tsc) orphaned; update all spawn() invocations that pass shell:
useShell to instead avoid shell on Windows (remove shell: useShell) or, if shell
is required, track and kill the actual child process tree (use a cross-platform
tree-kill approach or spawn with {detached: true} and kill by process group) and
replace await once(previousAppProcess, "exit") with waiting for the real child
exit event; look for symbols previousAppProcess, child.kill, spawn(...) calls
around the places noted and ensure the code kills the full process tree (or
disables shell wrapping) and awaits the true child process exit.

In `@templates/create/nest/src/main.ts.hbs`:
- Line 8: The import of AppModule in the generated Deno entrypoint is missing
the required .ts extension; update the import statement that references
AppModule (and any local module imports used by bootstrap()) to include the .ts
extension (e.g., import { AppModule } from "./app.module.ts") so Deno can
resolve the module and allow bootstrap() to run correctly.

In `@templates/create/nest/src/prisma.service.ts.hbs`:
- Around line 2-3: The import for prismaClientOptions uses "./lib/prisma"
without the Deno extension; update the line importing prismaClientOptions so it
conditionally appends ".ts" when packageManager is "deno" (the same pattern as
the generated client import) — e.g. change the import to import {
prismaClientOptions } from "./lib/prisma{{`#if` (eq packageManager
\"deno\")}}.ts{{/if}}"; so the template resolves correctly in Deno environments
and still works for other package managers.

In `@templates/create/turborepo/apps/api/src/index.ts.hbs`:
- Around line 46-48: The PORT parsing currently converts empty or whitespace
strings to 0 (since Number() yields 0), causing the app to bind to ephemeral
port 0; update the logic that defines rawPort/parsedPort/port to trim and
validate the raw string first (e.g., set rawPort = (process.env.PORT ||
'').trim()), only parse if rawPort is non-empty, and require parsedPort to be
finite and within 0–65535 before using it; otherwise fall back to 3000.

---

Duplicate comments:
In `@src/utils/package-manager.ts`:
- Around line 182-188: The helper usesNodeStyleRuntime currently treats
packageManager === undefined as false, which silently skips dotenv imports;
update the logic to fail fast when packageManager is undefined by adding an
explicit check in requiresDotenvConfigImport (or at the top of
usesNodeStyleRuntime) that throws a clear error or logs a warning and returns a
safe default; specifically locate the functions usesNodeStyleRuntime and
requiresDotenvConfigImport and either: 1) throw a descriptive error when
packageManager is undefined, or 2) log a warning and assume a Node-style manager
(e.g., npm) before performing the existing bun/deno checks so behavior is
explicit.

In `@templates/create/elysia/README.md.hbs`:
- Around line 20-24: The README template has inconsistent spacing: add a blank
line before the "4. Seed the database:" step in
templates/create/elysia/README.md.hbs so it matches the blank-line formatting
used for steps 2 and 3; update the block that renders `{{runScriptCommand
packageManager "db:migrate"}}`/`{{runScriptCommand packageManager "db:seed"}}`
to insert an empty line between the migrate command line and the "4. Seed the
database:" line so the generated README has consistent visual spacing.

In `@templates/create/elysia/src/lib/prisma.ts.hbs`:
- Around line 5-10: Duplicate conditional blocks importing and instantiating
PrismaPg for provider values "postgresql" and "cockroachdb" should be
consolidated into a single conditional to avoid repetition; update both the
import and the adapter instantiation sections in the template so they use a
combined condition (e.g., an or helper or a single check that matches either
provider) referencing the provider variable and the PrismaPg symbol so only one
"{{`#if` ...}} import { PrismaPg } from "@prisma/adapter-pg"; {{/if}}" and one
adapter instantiation block remain for both PostgreSQL and CockroachDB.

In `@templates/create/nest/README.md.hbs`:
- Around line 18-25: Add a blank line before the "4. Seed the database:" list
item to match the spacing used between earlier numbered steps; update the
template around the "3. Run your first migration:" block that contains
`{{runScriptCommand packageManager "db:migrate"}}` so there is a separating
blank line before the `{{runScriptCommand packageManager "db:seed"}}` line for
step "4." to keep consistent formatting.

In `@templates/create/nest/src/lib/prisma.ts.hbs`:
- Around line 6-11: Duplicate conditional import blocks for PostgreSQL and
CockroachDB should be consolidated: replace the two separate {{`#if` (eq provider
"postgresql")}} ... {{/if}} and {{`#if` (eq provider "cockroachdb")}} ... {{/if}}
import blocks with a single combined conditional that checks either provider
(e.g., {{`#if` (or (eq provider "postgresql") (eq provider "cockroachdb"))}}
import { PrismaPg } from "@prisma/adapter-pg"; {{/if}}) and apply the same
consolidation for the later duplicate at lines 32-41; remove the redundant
block(s) so the import appears only once when provider is postgresql or
cockroachdb.

In `@templates/create/nest/src/main.ts.hbs`:
- Line 19: The bootstrap() call at the entrypoint is currently unhandled; update
the invocation of the bootstrap function so any rejection from
NestFactory.create() or app.listen() is caught—call bootstrap().catch(err => {
console.error('Bootstrap failed', err); process.exit(1); }) — reference the
bootstrap function and ensure the catch logs the error and calls process.exit(1)
to exit non‑zero on failure.
🪄 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: 3a79c9d7-67ca-4f50-a110-88b282b47566

📥 Commits

Reviewing files that changed from the base of the PR and between 077734e and 29d2d3f.

📒 Files selected for processing (14)
  • src/tasks/install.ts
  • src/utils/package-manager.ts
  • templates/create/elysia/README.md.hbs
  • templates/create/elysia/src/index.ts.hbs
  • templates/create/elysia/src/lib/prisma.ts.hbs
  • templates/create/hono/README.md.hbs
  • templates/create/hono/src/index.ts.hbs
  • templates/create/hono/src/lib/prisma.ts.hbs
  • templates/create/nest/README.md.hbs
  • templates/create/nest/scripts/dev.ts.hbs
  • templates/create/nest/src/lib/prisma.ts.hbs
  • templates/create/nest/src/main.ts.hbs
  • templates/create/nest/src/prisma.service.ts.hbs
  • templates/create/turborepo/apps/api/src/index.ts.hbs

Comment thread templates/create/elysia/src/index.ts.hbs
Comment thread templates/create/elysia/src/index.ts.hbs Outdated
Comment thread templates/create/nest/scripts/dev.ts.hbs Outdated
Comment thread templates/create/nest/src/main.ts.hbs Outdated
Comment thread templates/create/nest/src/prisma.service.ts.hbs Outdated
Comment thread templates/create/turborepo/apps/api/src/index.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 (3)
templates/create/elysia/src/index.ts.hbs (2)

6-7: ⚠️ Potential issue | 🔴 Critical

Add the .ts extension for Deno in the prisma import.

This issue was flagged in a previous review and remains unaddressed. Deno requires explicit file extensions on local imports. The generated Deno entrypoint will fail to resolve ./lib/prisma without the .ts extension.

Proposed fix
-import { prisma } from "./lib/prisma";
+import { prisma } from "./lib/prisma{{`#if` (eq packageManager "deno")}}.ts{{/if}}";
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@templates/create/elysia/src/index.ts.hbs` around lines 6 - 7, The import for
the Prisma helper is missing a Deno file extension and will fail to resolve;
update the import statement that references "./lib/prisma" (the module providing
prisma) to point to "./lib/prisma.ts" so Deno can load the local module
correctly—locate the import in the template where it reads import { prisma }
from "./lib/prisma" and change it to include the .ts extension.

4-5: ⚠️ Potential issue | 🔴 Critical

Use Elysia's Deno API instead of the Node adapter for Deno package managers.

This issue was flagged in a previous review and remains unaddressed. The template has runtime-aware environment variable access (line 10) but unconditionally uses @elysiajs/node adapter and .listen(). For Deno, Elysia's native integration uses Deno.serve({ port }, app.fetch) without the Node adapter.

This architectural inconsistency will cause runtime failures when packageManager is "deno".

Proposed fix approach

The template needs to be restructured to:

  1. Conditionally import @elysiajs/node only for non-Deno runtimes
  2. Create Elysia without adapter: node() for Deno
  3. Use Deno.serve({ port }, app.fetch) instead of .listen(port) for Deno

This requires significant template restructuring with Handlebars conditionals.

Also applies to: 15-15, 31-31

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

In `@templates/create/elysia/src/index.ts.hbs` around lines 4 - 5, The template
unconditionally imports node adapter and calls app.listen which breaks Deno;
update the template to conditionally import "@elysiajs/node" only for non-Deno
package managers, instantiate new Elysia() without adapter when packageManager
=== "deno" (keep adapter: node() only for other runtimes), and replace
app.listen(port) with Deno.serve({ port }, app.fetch) for the Deno branch;
adjust Handlebars conditionals around the import, Elysia construction, and the
server start logic (references: import { node } from "@elysiajs/node"; new
Elysia(...); app.listen(...); Deno.serve({ port }, app.fetch)).
templates/create/nest/src/main.ts.hbs (1)

8-8: ⚠️ Potential issue | 🔴 Critical

Add the .ts extension for Deno in the AppModule import.

This issue was flagged in a previous review and remains unaddressed. Deno requires explicit file extensions on local imports. The generated Deno entrypoint will fail to load ./app.module without the .ts extension.

Proposed fix
-import { AppModule } from "./app.module";
+import { AppModule } from "./app.module{{`#if` (eq packageManager "deno")}}.ts{{/if}}";
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@templates/create/nest/src/main.ts.hbs` at line 8, The import for AppModule in
the Deno/Nest entrypoint lacks the required .ts extension, causing Deno to fail
to resolve the module; update the import statement that currently references
"./app.module" (where AppModule is imported) to explicitly use "./app.module.ts"
so the generated Deno entrypoint loads correctly and preserve the AppModule
symbol name.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@templates/create/elysia/src/index.ts.hbs`:
- Around line 10-13: rawPort/parsedPort/port logic incorrectly treats empty or
whitespace PORT as valid because Number('') === 0; update the code that computes
parsedPort to first normalize rawPort (trim and ensure it's non-empty) or
explicitly check rawPort !== '' && rawPort.trim() !== '' before converting; then
only call Number(rawPort) (or parseInt) when non-empty, falling back to the
default 3000 otherwise so Number.isFinite(parsedPort) won't accept an empty
string as 0.

In `@templates/create/hono/src/index.ts.hbs`:
- Around line 31-34: The current port parsing uses rawPort -> parsedPort -> port
(variables rawPort, parsedPort, port) but treats empty or whitespace-only PORT
values as Number('') === 0, causing port 0 to be selected; fix by treating
empty/whitespace rawPort as “no value” before converting: check rawPort (from
Deno.env.get("PORT") or process.env.PORT), trim and if it's empty treat as
undefined/NaN so that parsedPort becomes invalid and the existing fallback logic
picks 3000; update the parsedPort computation to first guard with
rawPort?.trim() and only call Number(...) when non-empty, leaving the final port
selection logic unchanged.

In `@templates/create/nest/src/main.ts.hbs`:
- Around line 12-15: The port parsing treats an empty or whitespace PORT value
as valid because Number('') === 0; update the logic around
rawPort/parsedPort/port to treat empty or whitespace-only rawPort as unset
before converting: trim rawPort and check it's non-empty (e.g., rawPort &&
rawPort.trim() !== '') then parse to Number and validate
(Number.isFinite(parsedPort) && parsedPort >= 0 && parsedPort <= 65535)
otherwise fall back to 3000; modify the code that produces parsedPort and port
to perform the trim-and-empty check so empty/whitespace PORT values no longer
resolve to 0.

---

Duplicate comments:
In `@templates/create/elysia/src/index.ts.hbs`:
- Around line 6-7: The import for the Prisma helper is missing a Deno file
extension and will fail to resolve; update the import statement that references
"./lib/prisma" (the module providing prisma) to point to "./lib/prisma.ts" so
Deno can load the local module correctly—locate the import in the template where
it reads import { prisma } from "./lib/prisma" and change it to include the .ts
extension.
- Around line 4-5: The template unconditionally imports node adapter and calls
app.listen which breaks Deno; update the template to conditionally import
"@elysiajs/node" only for non-Deno package managers, instantiate new Elysia()
without adapter when packageManager === "deno" (keep adapter: node() only for
other runtimes), and replace app.listen(port) with Deno.serve({ port },
app.fetch) for the Deno branch; adjust Handlebars conditionals around the
import, Elysia construction, and the server start logic (references: import {
node } from "@elysiajs/node"; new Elysia(...); app.listen(...); Deno.serve({
port }, app.fetch)).

In `@templates/create/nest/src/main.ts.hbs`:
- Line 8: The import for AppModule in the Deno/Nest entrypoint lacks the
required .ts extension, causing Deno to fail to resolve the module; update the
import statement that currently references "./app.module" (where AppModule is
imported) to explicitly use "./app.module.ts" so the generated Deno entrypoint
loads correctly and preserve the AppModule symbol name.
🪄 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: 688bc85c-74cd-45f8-9a04-46332e4ae423

📥 Commits

Reviewing files that changed from the base of the PR and between 29d2d3f and ccd2ec3.

📒 Files selected for processing (4)
  • templates/create/elysia/src/index.ts.hbs
  • templates/create/hono/src/index.ts.hbs
  • templates/create/nest/src/main.ts.hbs
  • templates/create/turborepo/apps/api/src/index.ts.hbs

Comment thread templates/create/elysia/src/index.ts.hbs Outdated
Comment thread templates/create/hono/src/index.ts.hbs Outdated
Comment thread templates/create/nest/src/main.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: 4

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

Inline comments:
In `@templates/create/elysia/src/index.ts.hbs`:
- Around line 15-16: The port selection logic uses Number.isFinite(parsedPort)
which allows non-integer values like 3000.5; update the condition that computes
const port to enforce integer ports by requiring Number.isInteger(parsedPort)
(or adding && Number.isInteger(parsedPort)) in the ternary that references
parsedPort so only integer values in 0..65535 are accepted, falling back to 3000
otherwise; update any related validation logic that relies on parsedPort being
an integer (e.g., server startup paths) to use the same check.

In `@templates/create/hono/src/index.ts.hbs`:
- Around line 31-34: The port validation allows non-integer numeric strings like
"3000.5"; update the logic that computes port (using variables rawPort,
parsedPort, and port) to require an integer by adding
Number.isInteger(parsedPort) (or equivalent integer check) to the existing
condition so only integer values within 0–65535 are accepted; if the parsed
value fails the integer check, fall back to the default 3000 as currently done.

In `@templates/create/nest/scripts/dev.ts.hbs`:
- Around line 95-99: Signal handlers are registered before the const tscProcess
is initialized which can trigger a TDZ ReferenceError when a signal arrives; to
fix, declare tscProcess in the outer scope before registering handlers (e.g.,
change the const to a let/undefined declaration) and then assign the spawned
process returned by spawn to tscProcess afterwards, ensuring
shutdown/killProcess use the already-declared tscProcess variable (refer to
tscProcess, spawn, shutdown, and killProcess in your changes).
- Line 71: The dev script currently calls fs.watch(distDir, { recursive: true },
...) unconditionally which fails on Linux with Node 18.x; update the watch
creation (symbol: distWatcher) to build an options object that only sets
recursive: true when process.platform is 'win32' or 'darwin' and otherwise omits
that property, then call fs.watch(distDir, options, (_eventType, filename) => {
... }) so the watcher is compatible across platforms and Node versions.
🪄 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: 09eb0c92-892b-4782-be88-9bc5be936f17

📥 Commits

Reviewing files that changed from the base of the PR and between ccd2ec3 and 9f6caf2.

📒 Files selected for processing (10)
  • templates/create/elysia/package.json.hbs
  • templates/create/elysia/src/index.ts.hbs
  • templates/create/hono/src/index.ts.hbs
  • templates/create/nest/scripts/dev.ts.hbs
  • templates/create/nest/src/app.module.ts.hbs
  • templates/create/nest/src/main.ts.hbs
  • templates/create/nest/src/prisma.service.ts.hbs
  • templates/create/nest/src/users.controller.ts.hbs
  • templates/create/nest/src/users.service.ts.hbs
  • templates/create/turborepo/apps/api/src/index.ts.hbs

Comment thread templates/create/elysia/src/index.ts.hbs Outdated
Comment thread templates/create/hono/src/index.ts.hbs Outdated
Comment thread templates/create/nest/scripts/dev.ts.hbs Outdated
Comment thread templates/create/nest/scripts/dev.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: 2

🤖 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 237-247: The current check `if (!projectNameInput)` treats an
explicit empty string as a cancel and prevents `validateProjectName()` from
running; change the guard to only treat an actual undefined as cancellation
(e.g., `projectNameInput === undefined`) so that `""` flows into
`String(projectNameInput).trim()` and `validateProjectName(projectName)` can
surface the validation error; update the logic around `projectNameInput`,
`projectName`, and the `cancel()` call accordingly, keeping
`promptForProjectName()` and `DEFAULT_PROJECT_NAME` behavior unchanged.

In `@src/utils/package-manager.ts`:
- Around line 228-235: The start script currently returns `tsx ${builtEntrypoint
?? sourceEntrypoint}`, which will break production installs because `tsx` is
only added to devDependencies; update the switch in package-manager.ts so that
for case "start" it returns `node ${builtEntrypoint}` when builtEntrypoint is
defined, otherwise return `tsx ${sourceEntrypoint}`; keep
`writeCreateTemplateDependencies()` as-is (it should continue adding `tsx` to
devDependencies) so production installs use `node` for built entrypoints and
developer runs use `tsx` for source entrypoints.
🪄 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: 707a748b-4214-4cb4-968a-9121cf672c29

📥 Commits

Reviewing files that changed from the base of the PR and between 9f6caf2 and 1a98f3e.

📒 Files selected for processing (7)
  • src/commands/create.ts
  • src/constants/dependencies.ts
  • src/tasks/install.ts
  • src/templates/shared.ts
  • src/utils/package-manager.ts
  • templates/create/elysia/package.json.hbs
  • templates/create/nest/package.json.hbs

Comment thread src/commands/create.ts
Comment thread src/utils/package-manager.ts
@AmanVarshney01 AmanVarshney01 merged commit 7554e7a into main Apr 7, 2026
6 checks passed
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.

2 participants