feat: Add Elysia and Nest create templates#31
Conversation
|
Note Reviews pausedIt 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 Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis pull request adds support for two new project templates ( Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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
|
There was a problem hiding this comment.
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 | 🟡 MinorPipeline failure: oxfmt formatting check.
The CI pipeline reports an
oxfmtformatting failure. Runoxfmtlocally 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 | 🟡 MinorAddress the formatting failure from the pipeline.
The CI pipeline reports that
oxfmt --check .failed on this file. Runoxfmt(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
📒 Files selected for processing (43)
README.mdsrc/commands/create.tssrc/constants/dependencies.tssrc/tasks/install.tssrc/templates/shared.tssrc/types.tssrc/utils/package-manager.tstemplates/create/elysia/README.md.hbstemplates/create/elysia/deno.json.hbstemplates/create/elysia/package.json.hbstemplates/create/elysia/prisma.config.ts.hbstemplates/create/elysia/prisma/schema.prisma.hbstemplates/create/elysia/prisma/seed.ts.hbstemplates/create/elysia/src/index.ts.hbstemplates/create/elysia/src/lib/prisma.ts.hbstemplates/create/elysia/tsconfig.jsontemplates/create/hono/README.md.hbstemplates/create/hono/package.json.hbstemplates/create/hono/prisma.config.tstemplates/create/hono/prisma.config.ts.hbstemplates/create/hono/prisma/schema.prisma.hbstemplates/create/hono/prisma/seed.ts.hbstemplates/create/hono/src/index.ts.hbstemplates/create/hono/src/lib/prisma.ts.hbstemplates/create/nest/.gitignoretemplates/create/nest/.yarnrc.yml.hbstemplates/create/nest/README.md.hbstemplates/create/nest/deno.json.hbstemplates/create/nest/package.json.hbstemplates/create/nest/prisma.config.ts.hbstemplates/create/nest/prisma/schema.prisma.hbstemplates/create/nest/prisma/seed.ts.hbstemplates/create/nest/scripts/dev.ts.hbstemplates/create/nest/src/app.controller.ts.hbstemplates/create/nest/src/app.module.ts.hbstemplates/create/nest/src/lib/prisma.ts.hbstemplates/create/nest/src/main.ts.hbstemplates/create/nest/src/prisma.service.ts.hbstemplates/create/nest/src/users.controller.ts.hbstemplates/create/nest/src/users.service.ts.hbstemplates/create/nest/tsconfig.jsontemplates/create/tanstack-start/prisma/schema.prisma.hbstemplates/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
There was a problem hiding this comment.
Actionable comments posted: 8
♻️ Duplicate comments (2)
templates/create/elysia/src/index.ts.hbs (1)
10-10:⚠️ Potential issue | 🟡 MinorPort parsing can produce
NaNfor invalid env values.This pattern appears in multiple templates (elysia, hono, nest, turborepo). A malformed
PORTenvironment variable (e.g.,"abc") will result inNaNbeing 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 | 🟠 MajorBound and harden the
dotenv/configscan before using it on arbitrary directories.This helper now walks whatever
projectDirpoints at, but it still has no recursion guard and letsreaddir/readFileerrors 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
📒 Files selected for processing (43)
README.mdsrc/commands/create.tssrc/constants/dependencies.tssrc/tasks/install.tssrc/templates/shared.tssrc/types.tssrc/utils/package-manager.tstemplates/create/elysia/README.md.hbstemplates/create/elysia/deno.json.hbstemplates/create/elysia/package.json.hbstemplates/create/elysia/prisma.config.ts.hbstemplates/create/elysia/prisma/schema.prisma.hbstemplates/create/elysia/prisma/seed.ts.hbstemplates/create/elysia/src/index.ts.hbstemplates/create/elysia/src/lib/prisma.ts.hbstemplates/create/elysia/tsconfig.jsontemplates/create/hono/README.md.hbstemplates/create/hono/package.json.hbstemplates/create/hono/prisma.config.tstemplates/create/hono/prisma.config.ts.hbstemplates/create/hono/prisma/schema.prisma.hbstemplates/create/hono/prisma/seed.ts.hbstemplates/create/hono/src/index.ts.hbstemplates/create/hono/src/lib/prisma.ts.hbstemplates/create/nest/.gitignoretemplates/create/nest/.yarnrc.yml.hbstemplates/create/nest/README.md.hbstemplates/create/nest/deno.json.hbstemplates/create/nest/package.json.hbstemplates/create/nest/prisma.config.ts.hbstemplates/create/nest/prisma/schema.prisma.hbstemplates/create/nest/prisma/seed.ts.hbstemplates/create/nest/scripts/dev.ts.hbstemplates/create/nest/src/app.controller.ts.hbstemplates/create/nest/src/app.module.ts.hbstemplates/create/nest/src/lib/prisma.ts.hbstemplates/create/nest/src/main.ts.hbstemplates/create/nest/src/prisma.service.ts.hbstemplates/create/nest/src/users.controller.ts.hbstemplates/create/nest/src/users.service.ts.hbstemplates/create/nest/tsconfig.jsontemplates/create/tanstack-start/prisma/schema.prisma.hbstemplates/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
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (6)
templates/create/nest/src/main.ts.hbs (1)
19-19:⚠️ Potential issue | 🟠 MajorHandle bootstrap rejections at the entrypoint.
Line 19 discards the promise returned by
bootstrap(), so startup failures fromNestFactory.create()orapp.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 | 🟡 MinorMinor 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
undefinedpackageManager silently treated as Bun/Deno.When
packageManagerisundefined,requiresDotenvConfigImportreturnsfalse, which could silently skip adding thedotenv/configimport 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 | 🔵 TrivialSame 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 | 🟡 MinorMinor 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 | 🔵 TrivialConsider consolidating duplicate PostgreSQL/CockroachDB blocks.
Both PostgreSQL and CockroachDB use identical
PrismaPgimport and adapter instantiation. While functionally correct, consolidating would reduce template duplication.♻️ Proposed refactor using an `or` helper
If an
orhelper is registered (or can be added):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
📒 Files selected for processing (14)
src/tasks/install.tssrc/utils/package-manager.tstemplates/create/elysia/README.md.hbstemplates/create/elysia/src/index.ts.hbstemplates/create/elysia/src/lib/prisma.ts.hbstemplates/create/hono/README.md.hbstemplates/create/hono/src/index.ts.hbstemplates/create/hono/src/lib/prisma.ts.hbstemplates/create/nest/README.md.hbstemplates/create/nest/scripts/dev.ts.hbstemplates/create/nest/src/lib/prisma.ts.hbstemplates/create/nest/src/main.ts.hbstemplates/create/nest/src/prisma.service.ts.hbstemplates/create/turborepo/apps/api/src/index.ts.hbs
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (3)
templates/create/elysia/src/index.ts.hbs (2)
6-7:⚠️ Potential issue | 🔴 CriticalAdd the
.tsextension for Deno in theprismaimport.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/prismawithout the.tsextension.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 | 🔴 CriticalUse 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/nodeadapter and.listen(). For Deno, Elysia's native integration usesDeno.serve({ port }, app.fetch)without the Node adapter.This architectural inconsistency will cause runtime failures when
packageManageris"deno".Proposed fix approach
The template needs to be restructured to:
- Conditionally import
@elysiajs/nodeonly for non-Deno runtimes- Create
Elysiawithoutadapter: node()for Deno- Use
Deno.serve({ port }, app.fetch)instead of.listen(port)for DenoThis 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 | 🔴 CriticalAdd the
.tsextension for Deno in theAppModuleimport.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.modulewithout the.tsextension.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
📒 Files selected for processing (4)
templates/create/elysia/src/index.ts.hbstemplates/create/hono/src/index.ts.hbstemplates/create/nest/src/main.ts.hbstemplates/create/turborepo/apps/api/src/index.ts.hbs
There was a problem hiding this comment.
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
📒 Files selected for processing (10)
templates/create/elysia/package.json.hbstemplates/create/elysia/src/index.ts.hbstemplates/create/hono/src/index.ts.hbstemplates/create/nest/scripts/dev.ts.hbstemplates/create/nest/src/app.module.ts.hbstemplates/create/nest/src/main.ts.hbstemplates/create/nest/src/prisma.service.ts.hbstemplates/create/nest/src/users.controller.ts.hbstemplates/create/nest/src/users.service.ts.hbstemplates/create/turborepo/apps/api/src/index.ts.hbs
There was a problem hiding this comment.
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
📒 Files selected for processing (7)
src/commands/create.tssrc/constants/dependencies.tssrc/tasks/install.tssrc/templates/shared.tssrc/utils/package-manager.tstemplates/create/elysia/package.json.hbstemplates/create/nest/package.json.hbs
What changed
elysiaandnestcreate templates--name .for scaffolding into the current directory--env-fileusagedotenvandtsxare added when the generated scaffold actually needs them.env-drivenPORTloading for empty-preset Hono/Elysia/Nest and the Turborepo API app