feat(cli): Add prisma 7 support and improve alchemy support #692
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughThis PR removes Cloudflare Wrangler/Workers support and templates, narrows deployment options to "alchemy" and "none", consolidates deployment flows around Alchemy, updates D1/SQLite and Prisma/libsql handling and dependency pins, adjusts prompts/validation/tests, and deletes tsdown/type export templates. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant Helpers
participant Templates
rect rgba(243,247,255,0.8)
Note over CLI,Helpers: Alchemy-only deployment flow (Wrangler removed)
User->>CLI: init/create project
CLI->>CLI: gather runtime, backend, webDeploy, serverDeploy, dbSetup
alt runtime == "workers"
CLI->>CLI: auto-select serverDeploy = "alchemy"
else
CLI->>CLI: serverDeploy = choice or none
end
CLI->>Helpers: run deployment & db setup
alt serverDeploy == "alchemy"
Helpers->>Helpers: setupAlchemyServerDeploy(serverDir, projectDir)
alt dbSetup == "d1"
Helpers->>Helpers: configure D1 for Alchemy (file DB or adapter)
else
Helpers->>Helpers: configure DATABASE_URL/secrets
end
else
Helpers->>Helpers: skip server deploy setup
end
Helpers-->>Templates: render templates (no wrangler outputs)
Templates-->>User: project files generated
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Areas needing extra attention:
Possibly related PRs
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/cli/test/deployment.test.ts (1)
342-345: Update the “different providers” scenarioBoth
webDeployandserverDeployare now"alchemy", so the test name no longer reflects what’s being exercised. Consider either adjusting the configuration to genuinely mix providers (if any remain) or rename/drop the case to avoid confusing future readers.apps/cli/src/prompts/server-deploy.ts (1)
78-89: Clean up dead branch and skip the redundant prompt
optionseither stays empty or contains just"alchemy", and the emptyif (options.length > 0)block is a leftover. We can streamline by returning the sole option immediately and avoid prompting the user for a foregone conclusion. Example:- if (options.length > 0) { - } - if (options.length === 0) { return "none"; } - const response = await select<ServerDeploy>({ + if (options.length === 1) { + return options[0]!.value; + } + + const response = await select<ServerDeploy>({ message: "Select server deployment", options, initialValue: DEFAULT_CONFIG.serverDeploy, })
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (44)
apps/cli/src/helpers/core/create-readme.ts(2 hunks)apps/cli/src/helpers/core/env-setup.ts(0 hunks)apps/cli/src/helpers/core/post-installation.ts(2 hunks)apps/cli/src/helpers/database-providers/d1-setup.ts(1 hunks)apps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.ts(1 hunks)apps/cli/src/helpers/deployment/server-deploy-setup.ts(2 hunks)apps/cli/src/helpers/deployment/web-deploy-setup.ts(3 hunks)apps/cli/src/helpers/deployment/workers/workers-next-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-nuxt-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-svelte-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-tanstack-start-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-vite-setup.ts(0 hunks)apps/cli/src/prompts/server-deploy.ts(3 hunks)apps/cli/src/prompts/web-deploy.ts(1 hunks)apps/cli/src/types.ts(1 hunks)apps/cli/src/utils/config-validation.ts(1 hunks)apps/cli/templates/api/orpc/server/tsconfig.json.hbs(1 hunks)apps/cli/templates/api/trpc/server/tsconfig.json.hbs(1 hunks)apps/cli/templates/auth/better-auth/server/base/tsconfig.json.hbs(1 hunks)apps/cli/templates/db/base/tsconfig.json.hbs(1 hunks)apps/cli/templates/db/drizzle/sqlite/drizzle.config.ts.hbs(0 hunks)apps/cli/templates/deploy/alchemy/alchemy.run.ts.hbs(4 hunks)apps/cli/templates/deploy/wrangler/server/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/nuxt/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/next/open-next.config.ts(0 hunks)apps/cli/templates/deploy/wrangler/web/react/next/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/react-router/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/tanstack-router/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/tanstack-start/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/solid/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/svelte/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/examples/ai/web/react/next/src/app/ai/page.tsx.hbs(2 hunks)apps/cli/templates/frontend/react/next/next.config.ts.hbs(2 hunks)apps/cli/templates/frontend/react/next/tsconfig.json.hbs(0 hunks)apps/cli/templates/packages/config/tsconfig.base.json.hbs(1 hunks)apps/cli/test/api.test.ts(2 hunks)apps/cli/test/auth.test.ts(1 hunks)apps/cli/test/backend-runtime.test.ts(2 hunks)apps/cli/test/config-package.test.ts(2 hunks)apps/cli/test/database-setup.test.ts(3 hunks)apps/cli/test/deployment.test.ts(15 hunks)apps/cli/test/frontend.test.ts(2 hunks)apps/cli/test/integration.test.ts(9 hunks)apps/web/src/lib/constant.ts(1 hunks)
💤 Files with no reviewable changes (17)
- apps/cli/templates/deploy/wrangler/web/react/tanstack-router/wrangler.jsonc.hbs
- apps/cli/templates/frontend/react/next/tsconfig.json.hbs
- apps/cli/templates/deploy/wrangler/web/react/next/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/solid/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/svelte/wrangler.jsonc.hbs
- apps/cli/src/helpers/deployment/workers/workers-vite-setup.ts
- apps/cli/src/helpers/deployment/workers/workers-tanstack-start-setup.ts
- apps/cli/src/helpers/deployment/workers/workers-nuxt-setup.ts
- apps/cli/templates/deploy/wrangler/web/nuxt/wrangler.jsonc.hbs
- apps/cli/templates/db/drizzle/sqlite/drizzle.config.ts.hbs
- apps/cli/src/helpers/deployment/workers/workers-svelte-setup.ts
- apps/cli/src/helpers/deployment/workers/workers-next-setup.ts
- apps/cli/templates/deploy/wrangler/web/react/next/open-next.config.ts
- apps/cli/templates/deploy/wrangler/web/react/tanstack-start/wrangler.jsonc.hbs
- apps/cli/src/helpers/core/env-setup.ts
- apps/cli/templates/deploy/wrangler/server/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/react/react-router/wrangler.jsonc.hbs
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/convex_rules.mdc)
**/*.{ts,tsx}: Use Id from './_generated/dataModel' to type document ids (e.g., Id<'users'>)
Ensure Record key/value types align with validators (e.g., v.record(v.id('users'), v.string()) => Record<Id<'users'>, string>)
Be strict with types for document ids; prefer Id<'table'> over string
Use 'as const' for string literals in discriminated unions
When using Array and Record types, declare with explicit generic types (e.g., const arr: Array = ...)
Files:
apps/cli/test/auth.test.tsapps/cli/test/config-package.test.tsapps/cli/test/deployment.test.tsapps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.tsapps/cli/test/integration.test.tsapps/cli/src/prompts/web-deploy.tsapps/cli/test/backend-runtime.test.tsapps/web/src/lib/constant.tsapps/cli/src/helpers/core/create-readme.tsapps/cli/test/frontend.test.tsapps/cli/test/database-setup.test.tsapps/cli/test/api.test.tsapps/cli/src/prompts/server-deploy.tsapps/cli/src/helpers/database-providers/d1-setup.tsapps/cli/src/types.tsapps/cli/src/utils/config-validation.tsapps/cli/src/helpers/deployment/server-deploy-setup.tsapps/cli/src/helpers/deployment/web-deploy-setup.tsapps/cli/src/helpers/core/post-installation.ts
**/*.{js,jsx,ts,tsx,mjs,cjs}
📄 CodeRabbit inference engine (.cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc)
**/*.{js,jsx,ts,tsx,mjs,cjs}: Do not use dotenv; Bun auto-loads .env
UseBun.serve()for HTTP/WebSockets; do not useexpress
Usebun:sqlitefor SQLite; do not usebetter-sqlite3
UseBun.redisfor Redis; do not useioredis
UseBun.sqlfor Postgres; do not usepgorpostgres.js
Use built-inWebSocket; do not usews
PreferBun.fileovernode:fsreadFile/writeFile
UseBun.$instead ofexecafor shelling out
Files:
apps/cli/test/auth.test.tsapps/cli/test/config-package.test.tsapps/cli/test/deployment.test.tsapps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.tsapps/cli/test/integration.test.tsapps/cli/src/prompts/web-deploy.tsapps/cli/test/backend-runtime.test.tsapps/web/src/lib/constant.tsapps/cli/src/helpers/core/create-readme.tsapps/cli/test/frontend.test.tsapps/cli/test/database-setup.test.tsapps/cli/test/api.test.tsapps/cli/src/prompts/server-deploy.tsapps/cli/src/helpers/database-providers/d1-setup.tsapps/cli/src/types.tsapps/cli/src/utils/config-validation.tsapps/cli/src/helpers/deployment/server-deploy-setup.tsapps/cli/src/helpers/deployment/web-deploy-setup.tsapps/cli/src/helpers/core/post-installation.ts
🧠 Learnings (5)
📚 Learning: 2025-08-24T18:01:11.544Z
Learnt from: CR
Repo: AmanVarshney01/create-better-t-stack PR: 0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-08-24T18:01:11.544Z
Learning: Applies to {**/package.json,**/@(jest|vitest).config.@(js|ts|mjs|cjs)} : Use `bun test` instead of `jest` or `vitest`
Applied to files:
apps/cli/test/config-package.test.ts
📚 Learning: 2025-06-08T17:57:33.083Z
Learnt from: Vijayabaskar56
Repo: AmanVarshney01/create-better-t-stack PR: 310
File: apps/cli/templates/frontend/angular/src/app.component.html:1-7
Timestamp: 2025-06-08T17:57:33.083Z
Learning: The Angular frontend template uses Tailwind CSS v4, which doesn't require a traditional tailwind.config.js configuration file.
Applied to files:
apps/cli/templates/frontend/react/next/next.config.ts.hbs
📚 Learning: 2025-08-24T18:00:39.152Z
Learnt from: CR
Repo: AmanVarshney01/create-better-t-stack PR: 0
File: .cursor/rules/convex_rules.mdc:0-0
Timestamp: 2025-08-24T18:00:39.152Z
Learning: Applies to **/*.{ts,tsx} : Use 'as const' for string literals in discriminated unions
Applied to files:
apps/web/src/lib/constant.ts
📚 Learning: 2025-08-24T18:01:11.544Z
Learnt from: CR
Repo: AmanVarshney01/create-better-t-stack PR: 0
File: .cursor/rules/use-bun-instead-of-node-vite-npm-pnpm.mdc:0-0
Timestamp: 2025-08-24T18:01:11.544Z
Learning: Applies to **/*.{js,jsx,ts,tsx,mjs,cjs} : Use `bun:sqlite` for SQLite; do not use `better-sqlite3`
Applied to files:
apps/cli/test/database-setup.test.tsapps/cli/src/helpers/core/post-installation.ts
📚 Learning: 2025-08-24T18:00:39.152Z
Learnt from: CR
Repo: AmanVarshney01/create-better-t-stack PR: 0
File: .cursor/rules/convex_rules.mdc:0-0
Timestamp: 2025-08-24T18:00:39.152Z
Learning: Applies to package.json : Add types/node to package.json when using Node.js built-in modules
Applied to files:
apps/cli/src/helpers/deployment/web-deploy-setup.ts
🧬 Code graph analysis (6)
apps/cli/test/config-package.test.ts (1)
apps/cli/test/test-utils.ts (1)
runTRPCTest(58-163)
apps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.ts (1)
apps/cli/src/helpers/deployment/server-deploy-setup.ts (1)
setupAlchemyServerDeploy(23-56)
apps/cli/src/prompts/server-deploy.ts (3)
apps/cli/src/types.ts (1)
WebDeploy(121-121)apps/cli/src/index.ts (1)
WebDeploy(263-263)apps/cli/src/constants.ts (1)
DEFAULT_CONFIG(40-40)
apps/cli/src/types.ts (2)
apps/cli/test/test-utils.ts (1)
WebDeploy(443-443)apps/cli/src/index.ts (1)
WebDeploy(263-263)
apps/cli/src/helpers/deployment/web-deploy-setup.ts (7)
apps/cli/src/helpers/deployment/alchemy/alchemy-next-setup.ts (1)
setupNextAlchemyDeploy(6-51)apps/cli/src/helpers/deployment/alchemy/alchemy-nuxt-setup.ts (1)
setupNuxtAlchemyDeploy(7-106)apps/cli/src/helpers/deployment/alchemy/alchemy-svelte-setup.ts (1)
setupSvelteAlchemyDeploy(7-77)apps/cli/src/helpers/deployment/alchemy/alchemy-tanstack-start-setup.ts (1)
setupTanStackStartAlchemyDeploy(7-102)apps/cli/src/helpers/deployment/alchemy/alchemy-tanstack-router-setup.ts (1)
setupTanStackRouterAlchemyDeploy(6-33)apps/cli/src/helpers/deployment/alchemy/alchemy-react-router-setup.ts (1)
setupReactRouterAlchemyDeploy(6-32)apps/cli/src/helpers/deployment/alchemy/alchemy-solid-setup.ts (1)
setupSolidAlchemyDeploy(6-32)
apps/cli/src/helpers/core/post-installation.ts (3)
apps/cli/src/types.ts (2)
Runtime(21-21)DatabaseSetup(80-80)apps/cli/test/test-utils.ts (2)
Runtime(436-436)DatabaseSetup(445-445)apps/cli/src/index.ts (2)
Runtime(256-256)DatabaseSetup(261-261)
🔇 Additional comments (18)
apps/web/src/lib/constant.ts (1)
121-122: Formatting change approved.The multi-line description for "native-uniwind" improves readability without changing the value or behavior.
apps/cli/templates/auth/better-auth/server/base/tsconfig.json.hbs (1)
8-8: LGTM! Wrangler conditional removed correctly.The removal of the conditional
typesblock for wrangler deployments is clean and the JSON syntax is correct (no trailing comma on the last property).apps/cli/templates/api/orpc/server/tsconfig.json.hbs (1)
8-8: LGTM! Consistent with wrangler removal.The conditional
typesblock has been correctly removed, maintaining valid JSON structure.apps/cli/templates/db/base/tsconfig.json.hbs (1)
8-8: LGTM! Worker configuration types removed correctly.The conditional block referencing
worker-configuration.d.tshas been properly removed as part of the wrangler deprecation.apps/cli/templates/api/trpc/server/tsconfig.json.hbs (1)
8-8: LGTM! Final wrangler conditional removed.This completes the consistent removal of wrangler-specific
typesconditionals across all tsconfig templates.apps/cli/templates/packages/config/tsconfig.base.json.hbs (1)
29-30: Correctly expanded condition to include both deployment targets.The change properly includes
@cloudflare/workers-typeswhen eitherserverDeployorwebDeployis set to "alchemy". Verification confirms thatwebDeploy="alchemy"is a valid configuration option used extensively throughout test files and source code (deployment setup, environment setup, README generation, and template management).apps/cli/templates/frontend/react/next/next.config.ts.hbs (2)
1-3: LGTM! Conditional import correctly restricted to Alchemy deployment.The narrowed conditional properly imports the OpenNext Cloudflare initialization only for Alchemy deployments, which aligns with the removal of Wrangler support.
16-18: No actionable changes required—conditional initialization is correct.The "alchemy" deployment option is consistently used throughout the codebase. The conditional at lines 16–18 properly gates the Alchemy-specific initialization function and mirrors the import block structure. Test coverage shows the option is validated across multiple deployment scenarios (deployment.test.ts, integration.test.ts, and others). No breaking changes or inconsistencies detected.
apps/cli/templates/examples/ai/web/react/next/src/app/ai/page.tsx.hbs (2)
6-10: Correct removal of Wrangler from dynamic import condition.The updated condition properly restricts
next/dynamicimports to Alchemy deployments only, while other deployment options (including the deprecated Wrangler path) will use static imports. This aligns with the PR objective to remove Wrangler support.
15-28: Reject review comment—deployment platforms have different SSR requirements.The code is correct. Different deployment targets (Alchemy vs. others) legitimately require different handling. While the Response component is already marked
"use client", Alchemy deployments use dynamic imports withssr: falsebecause the platform may have specific SSR constraints or requirements that differ from other deployment options. The conditional logic appropriately reflects these platform differences rather than assuming all deployments work identically.Likely an incorrect or invalid review comment.
apps/cli/test/auth.test.ts (1)
486-486: LGTM - Consistent migration to Alchemy deployment.The serverDeploy value has been correctly updated to "alchemy" for the workers runtime test scenario, aligning with the PR's objective to remove Wrangler support.
apps/cli/test/api.test.ts (1)
604-604: LGTM - Workers runtime correctly configured with Alchemy.Both workers runtime test cases have been properly updated to use "alchemy" for serverDeploy, replacing the deprecated Wrangler option.
Also applies to: 638-638
apps/cli/test/config-package.test.ts (1)
35-52: LGTM - Complete test migration to Alchemy.The test case has been comprehensively updated to validate the Alchemy stack instead of Wrangler, with consistent updates to the test name, project name, and both webDeploy and serverDeploy configurations.
apps/cli/test/backend-runtime.test.ts (1)
73-73: LGTM - Workers runtime constraints properly enforced.Both changes correctly set serverDeploy to "alchemy" for workers runtime scenarios, maintaining the requirement that workers runtime must have a server deployment configuration.
Also applies to: 298-298
apps/cli/test/database-setup.test.ts (1)
48-48: LGTM - D1 database setup correctly configured with Alchemy.All D1 (Cloudflare SQLite) test scenarios have been properly updated to use "alchemy" for serverDeploy, which is the correct deployment target for Cloudflare Workers runtime that D1 requires.
Also applies to: 416-416, 493-493
apps/cli/test/frontend.test.ts (1)
475-475: LGTM - Web deployment tests updated consistently.Both web deployment constraint tests have been updated to use "alchemy" instead of the deprecated "wrangler" option, maintaining test coverage for web deployment scenarios.
Also applies to: 496-496
apps/cli/src/prompts/web-deploy.ts (1)
44-44: LGTM - Wrangler deployment option removed from UI.The available web deployment options have been correctly reduced to
["alchemy", "none"], effectively removing Wrangler from the user-facing deployment choices. This is a key change that enforces the migration at the UI level.apps/cli/test/integration.test.ts (1)
25-26: LGTM - Comprehensive integration test migration to Alchemy.All integration test scenarios have been systematically updated to use "alchemy" for both webDeploy and serverDeploy where applicable. The changes maintain complete test coverage across:
- Full-stack configurations (React, Nuxt, Solid)
- Frontend-only setups
- Cloudflare Workers scenarios
- Error and constraint validation cases
- Edge cases and complex configurations
The migration is thorough and consistent across all test categories.
Also applies to: 109-109, 173-173, 193-194, 235-236, 258-258, 325-325, 457-457, 480-481, 576-576
AmanVarshney01
force-pushed
the
remove-wrangler
branch
from
ef8e281 to
e60b2e9
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
This is the final PR Bugbot will review for you during this billing cycle
Your free Bugbot reviews will reset on December 7
Details
You are on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| (serverDeploy === "wrangler" || serverDeploy === "alchemy") && | ||
| orm === "prisma" | ||
| ) { | ||
| if (serverDeploy === "alchemy" && orm === "prisma") { |
There was a problem hiding this comment.
Bug: Hardcoded DB path breaks self backend.
The DATABASE_URL path is hardcoded to use "apps/server" but should use the targetApp2 variable that was already computed based on backend === "self". When using self backend, this creates an incorrect path pointing to apps/server/local.db instead of apps/web/local.db.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/cli/src/prompts/server-deploy.ts (1)
78-79: Remove dead code.This empty
ifstatement serves no purpose and should be removed to improve code clarity.Apply this diff:
- if (options.length > 0) { - } - if (options.length === 0) {
🧹 Nitpick comments (6)
apps/cli/templates/examples/ai/web/react/next/src/app/ai/page.tsx.hbs (1)
15-28: Consider documenting why Alchemy requiresssr: false.The dynamic import with
ssr: falseis now explicitly gated to Alchemy deployments. Adding a brief comment explaining why SSR must be disabled for Alchemy (e.g., edge runtime limitations, browser API usage, or performance considerations) would help future maintainers understand this constraint.For example:
{{#if (eq webDeploy "alchemy")}} +// Alchemy edge runtime requires client-side only rendering for Response component const Response = dynamic(apps/cli/src/helpers/core/create-readme.ts (2)
537-545: Unused_serverDeployparameter ingenerateDatabaseSetup
_serverDeployis now unused; the only caller passesoptions.serverDeploybut the value isn’t read anymore. You can simplify by dropping the parameter and corresponding argument if you don’t plan to reintroduce server-deploy‑specific branching here.
565-573: Clarify D1 setup step text to match new Alchemy behaviorFor
dbSetup === "d1", the content says “D1 local development and migrations are handled automatically by Alchemy…”, but it still appears under the “1. Start the local SQLite database:” step heading, which can be confusing.Consider inlining the step label into the conditional so the wording matches the behavior, e.g.:
-1. Start the local SQLite database: -${ - dbSetup === "d1" - ? "D1 local development and migrations are handled automatically by Alchemy during dev and deploy." - : `\`\`\`bash -cd ${dbLocalPath} && ${packageManagerRunCmd} db:local -\`\`\` -` -} +1. ${ + dbSetup === "d1" + ? "D1 development and migrations are handled automatically by Alchemy during dev and deploy." + : `Start the local SQLite database: +\`\`\`bash +cd ${dbLocalPath} && ${packageManagerRunCmd} db:local +\`\`\`` +}apps/cli/src/helpers/deployment/web-deploy-setup.ts (1)
12-51: Alchemy-only web deploy flow looks correct; minor duplication opportunityThe new
setupWebDeploycorrectly short-circuits non‑alchemy values, handles the combinedwebDeploy === "alchemy" && serverDeploy === "alchemy"case viasetupCombinedAlchemyDeploy, and otherwise dispatches to the appropriate Alchemy setup helper per frontend before adding@cloudflare/workers-typesat the root. This aligns with the alchemy‑only deployment model.Note that in the combined case,
setupCombinedAlchemyDeploy→setupAlchemyServerDeployalready callsaddAlchemyPackagesDependencies(projectDir), and you also call it here; this double-add is harmless but could be consolidated if you want to avoid redundant package.json writes.apps/cli/templates/deploy/alchemy/alchemy.run.ts.hbs (2)
22-25: D1 gating for imports/db-generate looks good; consider simplifyingcwdhandlingThe expanded condition for importing
D1Database/Execand runningdb-generatelines up with alldbusages and correctly covers the newwebDeploy: "alchemy" + backend: "self" + dbSetup: "d1"scenario.One thing to tighten up: in the self‑backend+D1 case where
serverDeploy !== "alchemy",Exec("db-generate", …)now runs withoutcwd, relying on a root‑leveldb:generatescript. GivenmigrationsDiralways points intopackages/db/..., it may be more robust to always rundb:generatefrompackages/dbwhenever this block executes, instead of only when both web and server deploy via Alchemy.You could simplify to something like:
-{{#if (and (or (eq serverDeploy "alchemy") (and (eq webDeploy "alchemy") (eq backend "self"))) (eq dbSetup "d1"))}} +{{#if (and (or (eq serverDeploy "alchemy") (and (eq webDeploy "alchemy") (eq backend "self"))) (eq dbSetup "d1"))}} await Exec("db-generate", { - {{#if (and (eq webDeploy "alchemy") (eq serverDeploy "alchemy"))}}cwd: "packages/db",{{/if}} + cwd: "packages/db", command: "{{packageManager}} run db:generate", }); const db = await D1Database("database", {and remove the conditional
cwdentirely.To be safe, please confirm that all templates hitting this code path have
packages/dbwith adb:generatescript before applying the change.Also applies to: 38-51
63-94: Self‑backend bindings for Next/TanStack Start duplicate server bindings – consider extractingThe new
backend === "self"bindings for Next (lines 63‑94) and TanStack Start (lines 137‑168) mirror the server Worker bindings (DB vs DATABASE_URL, CORS_ORIGIN, auth, AI, Polar, Turso, MySQL/Drizzle). This is good for parity and should make self‑backend web deployments behave consistently with the server Worker.The downside is that the bindings logic now lives in three places (server, Next, TanStack Start), which makes future changes to secrets or DB wiring easy to miss in one of them. If your templating setup supports it, consider extracting this block into a reusable partial or helper invoked from all three locations so updates stay in sync.
Also applies to: 137-168
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (44)
apps/cli/src/helpers/core/create-readme.ts(2 hunks)apps/cli/src/helpers/core/env-setup.ts(0 hunks)apps/cli/src/helpers/core/post-installation.ts(2 hunks)apps/cli/src/helpers/database-providers/d1-setup.ts(1 hunks)apps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.ts(1 hunks)apps/cli/src/helpers/deployment/server-deploy-setup.ts(2 hunks)apps/cli/src/helpers/deployment/web-deploy-setup.ts(3 hunks)apps/cli/src/helpers/deployment/workers/workers-next-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-nuxt-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-svelte-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-tanstack-start-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-vite-setup.ts(0 hunks)apps/cli/src/prompts/server-deploy.ts(3 hunks)apps/cli/src/prompts/web-deploy.ts(1 hunks)apps/cli/src/types.ts(1 hunks)apps/cli/src/utils/config-validation.ts(1 hunks)apps/cli/templates/api/orpc/server/tsconfig.json.hbs(1 hunks)apps/cli/templates/api/trpc/server/tsconfig.json.hbs(1 hunks)apps/cli/templates/auth/better-auth/server/base/tsconfig.json.hbs(1 hunks)apps/cli/templates/db/base/tsconfig.json.hbs(1 hunks)apps/cli/templates/db/drizzle/sqlite/drizzle.config.ts.hbs(0 hunks)apps/cli/templates/deploy/alchemy/alchemy.run.ts.hbs(4 hunks)apps/cli/templates/deploy/wrangler/server/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/nuxt/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/next/open-next.config.ts(0 hunks)apps/cli/templates/deploy/wrangler/web/react/next/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/react-router/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/tanstack-router/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/tanstack-start/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/solid/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/svelte/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/examples/ai/web/react/next/src/app/ai/page.tsx.hbs(2 hunks)apps/cli/templates/frontend/react/next/next.config.ts.hbs(2 hunks)apps/cli/templates/frontend/react/next/tsconfig.json.hbs(0 hunks)apps/cli/templates/packages/config/tsconfig.base.json.hbs(1 hunks)apps/cli/test/api.test.ts(2 hunks)apps/cli/test/auth.test.ts(1 hunks)apps/cli/test/backend-runtime.test.ts(2 hunks)apps/cli/test/config-package.test.ts(2 hunks)apps/cli/test/database-setup.test.ts(3 hunks)apps/cli/test/deployment.test.ts(15 hunks)apps/cli/test/frontend.test.ts(2 hunks)apps/cli/test/integration.test.ts(9 hunks)apps/web/src/lib/constant.ts(1 hunks)
💤 Files with no reviewable changes (17)
- apps/cli/templates/deploy/wrangler/server/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/react/next/open-next.config.ts
- apps/cli/templates/deploy/wrangler/web/react/tanstack-router/wrangler.jsonc.hbs
- apps/cli/src/helpers/deployment/workers/workers-svelte-setup.ts
- apps/cli/src/helpers/deployment/workers/workers-vite-setup.ts
- apps/cli/templates/deploy/wrangler/web/solid/wrangler.jsonc.hbs
- apps/cli/templates/frontend/react/next/tsconfig.json.hbs
- apps/cli/templates/deploy/wrangler/web/react/react-router/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/react/tanstack-start/wrangler.jsonc.hbs
- apps/cli/src/helpers/deployment/workers/workers-tanstack-start-setup.ts
- apps/cli/templates/deploy/wrangler/web/svelte/wrangler.jsonc.hbs
- apps/cli/src/helpers/deployment/workers/workers-next-setup.ts
- apps/cli/templates/deploy/wrangler/web/react/next/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/nuxt/wrangler.jsonc.hbs
- apps/cli/templates/db/drizzle/sqlite/drizzle.config.ts.hbs
- apps/cli/src/helpers/deployment/workers/workers-nuxt-setup.ts
- apps/cli/src/helpers/core/env-setup.ts
🚧 Files skipped from review as they are similar to previous changes (11)
- apps/web/src/lib/constant.ts
- apps/cli/templates/api/orpc/server/tsconfig.json.hbs
- apps/cli/test/frontend.test.ts
- apps/cli/templates/packages/config/tsconfig.base.json.hbs
- apps/cli/src/helpers/database-providers/d1-setup.ts
- apps/cli/templates/db/base/tsconfig.json.hbs
- apps/cli/src/utils/config-validation.ts
- apps/cli/templates/api/trpc/server/tsconfig.json.hbs
- apps/cli/test/config-package.test.ts
- apps/cli/test/database-setup.test.ts
- apps/cli/templates/auth/better-auth/server/base/tsconfig.json.hbs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-06-08T17:57:33.083Z
Learnt from: Vijayabaskar56
Repo: AmanVarshney01/create-better-t-stack PR: 310
File: apps/cli/templates/frontend/angular/src/app.component.html:1-7
Timestamp: 2025-06-08T17:57:33.083Z
Learning: The Angular frontend template uses Tailwind CSS v4, which doesn't require a traditional tailwind.config.js configuration file.
Applied to files:
apps/cli/templates/frontend/react/next/next.config.ts.hbs
🧬 Code graph analysis (5)
apps/cli/src/types.ts (2)
apps/cli/test/test-utils.ts (1)
WebDeploy(443-443)apps/cli/src/index.ts (1)
WebDeploy(263-263)
apps/cli/src/helpers/deployment/web-deploy-setup.ts (7)
apps/cli/src/helpers/deployment/alchemy/alchemy-next-setup.ts (1)
setupNextAlchemyDeploy(6-51)apps/cli/src/helpers/deployment/alchemy/alchemy-nuxt-setup.ts (1)
setupNuxtAlchemyDeploy(7-106)apps/cli/src/helpers/deployment/alchemy/alchemy-svelte-setup.ts (1)
setupSvelteAlchemyDeploy(7-77)apps/cli/src/helpers/deployment/alchemy/alchemy-tanstack-start-setup.ts (1)
setupTanStackStartAlchemyDeploy(7-102)apps/cli/src/helpers/deployment/alchemy/alchemy-tanstack-router-setup.ts (1)
setupTanStackRouterAlchemyDeploy(6-33)apps/cli/src/helpers/deployment/alchemy/alchemy-react-router-setup.ts (1)
setupReactRouterAlchemyDeploy(6-32)apps/cli/src/helpers/deployment/alchemy/alchemy-solid-setup.ts (1)
setupSolidAlchemyDeploy(6-32)
apps/cli/src/helpers/core/post-installation.ts (3)
apps/cli/src/types.ts (2)
Runtime(21-21)DatabaseSetup(80-80)apps/cli/test/test-utils.ts (2)
Runtime(436-436)DatabaseSetup(445-445)apps/cli/src/index.ts (2)
Runtime(256-256)DatabaseSetup(261-261)
apps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.ts (1)
apps/cli/src/helpers/deployment/server-deploy-setup.ts (1)
setupAlchemyServerDeploy(23-56)
apps/cli/src/prompts/server-deploy.ts (2)
apps/cli/src/types.ts (1)
WebDeploy(121-121)apps/cli/src/constants.ts (1)
DEFAULT_CONFIG(40-40)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (18)
apps/cli/templates/frontend/react/next/next.config.ts.hbs (1)
1-3: Verified: conditional logic and dependency management are correct.The import and initialization of
@opennextjs/cloudflareare properly gated to the Alchemy deployment path. Verification confirms the package is explicitly added as a dependency when Alchemy deployment is selected (viaalchemy-next-setup.ts), eliminating any risk of undefined references.apps/cli/templates/examples/ai/web/react/next/src/app/ai/page.tsx.hbs (1)
6-10: The review comment is incorrect and should be disregarded.The entire
AIPageis already marked with"use client"(line 1), making it a client-only component. This means SSR is already disabled at the page level. Additionally, theResponsecomponent itself is also marked with"use client". Since both the page and component are already client-side only, SSR compatibility is not a concern. The conditional import strategy (static for non-alchemy, dynamic for alchemy) has no impact on SSR behavior—both paths execute in the client context where SSR is irrelevant.Likely an incorrect or invalid review comment.
apps/cli/src/types.ts (1)
118-126: Web/Server deploy enums now alchemy-only look consistentLimiting
WebDeploySchemaandServerDeploySchemato"alchemy"and"none"aligns with the new single-provider deploy model and is type-safe with existing usages.apps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.ts (1)
37-40: Callsite update tosetupAlchemyServerDeploymatches new signatureUsing
setupAlchemyServerDeploy(serverDir, projectDir)is consistent with the updated helper signature and keeps server setup aligned with the combined Alchemy deploy flow.apps/cli/src/helpers/deployment/server-deploy-setup.ts (1)
6-21: Server deploy now cleanly defers combined Alchemy setup to web deployThe new
setupServerDeploylogic—early exit forserverDeploy === "none", and for the combinedserverDeploy === "alchemy" && webDeploy === "alchemy"case—avoids double-configuring the server whensetupCombinedAlchemyDeployis responsible. For server‑only Alchemy, callingsetupAlchemyServerDeploy(serverDir, projectDir)is consistent with the updated helper signature and keeps behavior focused on the alchemy path.apps/cli/test/auth.test.ts (1)
486-486: LGTM - Test configuration correctly updated.The test configuration properly reflects the migration from Wrangler to Alchemy for workers runtime deployment.
apps/cli/test/backend-runtime.test.ts (1)
73-73: LGTM - Workers runtime tests correctly updated.Both test configurations properly reflect the migration from Wrangler to Alchemy for Cloudflare Workers deployments.
Also applies to: 298-298
apps/cli/test/api.test.ts (1)
604-604: LGTM - API test configurations correctly updated.The test configurations properly reflect the migration to Alchemy for workers runtime scenarios.
Also applies to: 638-638
apps/cli/test/integration.test.ts (1)
25-26: LGTM - Integration tests comprehensively updated.All integration test scenarios have been properly updated to use Alchemy instead of Wrangler for both web and server deployments, ensuring consistent test coverage for the new deployment path.
Also applies to: 46-47, 67-67, 109-109, 173-173, 193-194, 235-236, 258-258, 279-279, 325-325, 480-481, 576-576
apps/cli/src/prompts/web-deploy.ts (3)
17-31: LGTM - Web deployment options correctly simplified.The removal of Wrangler from the deployment display logic correctly consolidates to Alchemy-only deployment paths.
44-44: LGTM - Available deployments correctly updated.The available deployments array now correctly excludes "wrangler", offering only "alchemy" and "none" options.
66-83: LGTM - Deployment addition logic correctly updated.The function correctly removes the Wrangler option and only considers Alchemy for deployment addition.
apps/cli/test/deployment.test.ts (1)
64-64: LGTM - Deployment tests comprehensively updated.All deployment test scenarios have been properly migrated from Wrangler to Alchemy, ensuring consistent test coverage for the consolidated deployment approach.
Also applies to: 85-85, 117-117, 197-197, 224-224, 253-253, 277-277, 322-323, 343-344, 364-364, 386-386, 408-409, 429-430, 510-511, 531-531
apps/cli/src/prompts/server-deploy.ts (3)
12-26: LGTM - Deployment display correctly simplified.The removal of Wrangler from the deployment display logic correctly consolidates to Alchemy-only deployment paths.
28-50: LGTM - Auto-selection logic correctly implemented.The function now auto-selects "alchemy" for workers runtime and "none" for other scenarios, removing the need for interactive prompting. This simplification aligns with the PR's goal of consolidating to Alchemy.
52-94: LGTM - Server deployment addition logic correctly simplified.The function correctly removes Wrangler support and simplifies the deployment addition flow to only consider Alchemy for workers runtime.
apps/cli/src/helpers/core/post-installation.ts (2)
120-129: LGTM - Post-installation instructions correctly updated.The condition properly reflects that SQLite local server should start for Alchemy deployments instead of Wrangler deployments.
246-350: LGTM - Database instructions correctly simplified.The function properly removes Wrangler-specific deployment guidance and consolidates to Alchemy-only paths. Parameter renames to
_runtimeand_backendcorrectly indicate they're now unused after the refactoring.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/cli/src/helpers/core/post-installation.ts (1)
397-425: Alchemy web dev command now explicitly usesalchemy devThe updated Alchemy web deploy instructions now surface
Dev: cd apps/web && ${runCmd} alchemy dev, which matches the intent to use the Alchemy dev command instead of the genericdevscript. Please just double‑check thatapps/webdefines analchemyscript (e.g., forwarding to the Alchemy CLI) so thatnpm|pnpm|bun run alchemy devworks as shown in the post‑install output.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
apps/cli/src/constants.ts(1 hunks)apps/cli/src/helpers/core/db-setup.ts(2 hunks)apps/cli/src/helpers/core/post-installation.ts(3 hunks)apps/cli/templates/frontend/react/next/next.config.ts.hbs(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/cli/templates/frontend/react/next/next.config.ts.hbs
🧰 Additional context used
🧬 Code graph analysis (2)
apps/cli/src/helpers/core/db-setup.ts (1)
apps/cli/src/utils/add-package-deps.ts (1)
addPackageDependency(6-59)
apps/cli/src/helpers/core/post-installation.ts (1)
apps/cli/src/types.ts (2)
Runtime(21-21)DatabaseSetup(80-80)
🔇 Additional comments (4)
apps/cli/src/constants.ts (1)
56-56: LGTM!The addition of the
libsqlversion to the dependency map is correct and aligns with the new libsql usage introduced in the database setup flow.apps/cli/src/helpers/core/db-setup.ts (1)
36-36: LGTM!Introducing
webDirat the function scope eliminates duplication and makes the code more maintainable.apps/cli/src/helpers/core/post-installation.ts (2)
121-129: SQLitedb:localgating now correctly scoped to Alchemy deploymentsConditionally showing
db:localonly when using SQLite with no explicit DB setup and eitherserverDeployorwebDeployset to"alchemy"keeps the Workers/D1 compatibility step aligned with the new Alchemy‑only deployment path. This looks consistent with the PR’s goal of dropping Wrangler while keeping Workers support via Alchemy.
246-254: Underscore‑prefixed_runtimeand_backendkeep the helper signature stableRenaming
runtime/backendparameters to_runtime/_backendingetDatabaseInstructionsis a reasonable way to keep the call signature backward‑compatible while making it clear they’re currently unused (and silencing unused‑parameter linting). The internal logic no longer depends on these, which matches the simplified, Alchemy‑focused database flow.
AmanVarshney01
force-pushed
the
remove-wrangler
branch
from
39d948b to
20ad0ad
Compare
| if (webDeploy === "alchemy" && serverDeploy !== "alchemy") { | ||
| instructions.push( | ||
| `${pc.bold("Deploy web with Alchemy:")}\n${pc.cyan("•")} Dev: ${`cd apps/web && ${runCmd} dev`}\n${pc.cyan("•")} Deploy: ${`cd apps/web && ${runCmd} deploy`}\n${pc.cyan("•")} Destroy: ${`cd apps/web && ${runCmd} destroy`}`, | ||
| `${pc.bold("Deploy web with Alchemy:")}\n${pc.cyan("•")} Dev: ${`cd apps/web && ${runCmd} alchemy dev`}\n${pc.cyan("•")} Deploy: ${`cd apps/web && ${runCmd} deploy`}\n${pc.cyan("•")} Destroy: ${`cd apps/web && ${runCmd} destroy`}`, |
There was a problem hiding this comment.
Bug: Inconsistent Alchemy Command Prefixes
Inconsistent alchemy command prefix in deployment instructions. The "Dev" command includes alchemy prefix (cd apps/web && ${runCmd} alchemy dev), but the "Deploy" and "Destroy" commands don't (cd apps/web && ${runCmd} deploy). This mismatch will cause the deploy and destroy commands to fail. All three should consistently use either just ${runCmd} deploy or ${runCmd} alchemy deploy.
| if (webDeploy === "alchemy" && serverDeploy !== "alchemy") { | ||
| instructions.push( | ||
| `${pc.bold("Deploy web with Alchemy:")}\n${pc.cyan("•")} Dev: ${`cd apps/web && ${runCmd} dev`}\n${pc.cyan("•")} Deploy: ${`cd apps/web && ${runCmd} deploy`}\n${pc.cyan("•")} Destroy: ${`cd apps/web && ${runCmd} destroy`}`, | ||
| `${pc.bold("Deploy web with Alchemy:")}\n${pc.cyan("•")} Dev: ${`cd apps/web && ${runCmd} alchemy dev`}\n${pc.cyan("•")} Deploy: ${`cd apps/web && ${runCmd} deploy`}\n${pc.cyan("•")} Destroy: ${`cd apps/web && ${runCmd} destroy`}`, |
There was a problem hiding this comment.
Bug: Alchemy Web Deployment: Command Prefix Error
The web Alchemy deployment instructions include an incorrect Dev command prefix. For web-only Alchemy deployment, the instruction shows cd apps/web && ${runCmd} alchemy dev, but should be cd apps/web && ${runCmd} dev since the alchemy scripts are defined in the root package.json (as dev: "alchemy dev"). The current format attempts to run npm run alchemy dev which is incorrect.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/cli/src/helpers/database-providers/d1-setup.ts (1)
20-22: Silent error handling may hide setup failures.The empty catch block on line 22 silently swallows all errors from
addEnvVariablesToFile. Consider logging the error for debugging purposes, or verify that silent failure is the intended behavior.apps/cli/src/helpers/core/post-installation.ts (1)
397-428: Inconsistent deployment command in web-only Alchemy instructions.Line 408 uses
${runCmd} alchemy devwhich is inconsistent with other deployment instructions. Line 416 (server-only Alchemy) and line 423 (combined Alchemy) both use${runCmd} devafter changing to the respective directory. Thealchemy devcommand appears to be incorrect.Apply this diff to fix the inconsistency:
- `${pc.bold("Deploy web with Alchemy:")}\n${pc.cyan("•")} Dev: ${`cd apps/web && ${runCmd} alchemy dev`}\n${pc.cyan("•")} Deploy: ${`cd apps/web && ${runCmd} deploy`}\n${pc.cyan("•")} Destroy: ${`cd apps/web && ${runCmd} destroy`}`, + `${pc.bold("Deploy web with Alchemy:")}\n${pc.cyan("•")} Dev: ${`cd apps/web && ${runCmd} dev`}\n${pc.cyan("•")} Deploy: ${`cd apps/web && ${runCmd} deploy`}\n${pc.cyan("•")} Destroy: ${`cd apps/web && ${runCmd} destroy`}`,
♻️ Duplicate comments (2)
apps/cli/src/helpers/database-providers/d1-setup.ts (1)
15-15: Critical: DATABASE_URL path doesn't respecttargetApp2variable.Line 15 hardcodes
"apps/server"but should use thetargetApp2variable computed on line 10. Whenbackend === "self", this creates the wrong pathapps/server/local.dbinstead ofapps/web/local.db.Apply this fix:
{ key: "DATABASE_URL", - value: `file:${path.join(projectDir, "apps/server", "local.db")}`, + value: `file:${path.join(projectDir, targetApp2, "local.db")}`, condition: true, },apps/cli/src/helpers/core/db-setup.ts (1)
81-84: Add existence check before accessingwebDir.This code adds libsql dependencies to
webDirwithout verifying the directory exists. The Prisma branch at line 68 guards itswebDiraccess withif (await fs.pathExists(webDir)). Ifapps/webdoesn't exist in certain project configurations,addPackageDependencywill fail when attempting to readpackage.json.Apply this diff to add the missing check:
if (database === "sqlite") { await addPackageDependency({ dependencies: ["drizzle-orm", "@libsql/client", "libsql"], devDependencies: ["drizzle-kit"], projectDir: dbPackageDir, }); - await addPackageDependency({ - dependencies: ["@libsql/client", "libsql"], - projectDir: webDir, - }); + if (await fs.pathExists(webDir)) { + await addPackageDependency({ + dependencies: ["@libsql/client", "libsql"], + projectDir: webDir, + }); + } } else if (database === "postgres") {
🧹 Nitpick comments (4)
apps/cli/src/helpers/database-providers/d1-setup.ts (1)
24-27: Consider reusingtargetApp2to eliminate duplication.Lines 24-27 duplicate the backend-based path logic already computed in
targetApp2on line 10.Apply this diff to reuse the variable:
- const serverDir = path.join( - projectDir, - backend === "self" ? "apps/web" : "apps/server", - ); + const serverDir = path.join(projectDir, targetApp2);apps/cli/templates/deploy/alchemy/alchemy.run.ts.hbs (3)
38-51: Exec + D1 initialization logic is consistent, but condition is duplicatedThe
Exec("db-generate", …)andD1Databaseinitialization share the same guard as the import block, sodbis always defined when referenced and never created unnecessarily. The only minor downside is repeating that long condition in multiple places; if this pattern spreads further, consider a small Handlebars helper (e.g.shouldUseD1) to centralize the logic and reduce drift risk.
63-94: Self-backend Next.js bindings look correct; consider tightening MySQL secret handlingThe new
backend === "self"bindings for Next.js are wired sensibly:
- D1 case uses
DB: db, matching the guarded D1 initialization above.- Non-D1, non-
noneDBs getDATABASE_URLwrapped withalchemy.secret, consistent with the server worker.- CORS, auth, AI, Polar, Turso, and MySQL drizzle bindings mirror the server worker’s environment, enabling the web worker to act as the backend.
One thing to consider: for
database === "mysql"+orm === "drizzle",DATABASE_PASSWORD(and possiblyDATABASE_USERNAME) are exposed as plain bindings while other sensitive values usealchemy.secret. That pattern already exists in the server worker block, but this change duplicates it into the web worker as well. It may be worth switching at leastDATABASE_PASSWORDtoalchemy.secret(process.env.DATABASE_PASSWORD)here and in the server bindings for consistency and stronger secret handling.
137-168: TanStackStart self-backend bindings mirror Next.js; consider de-duplicating shared binding logicThis block correctly mirrors the Next.js self-backend bindings, so TanStackStart gets the same D1/
DATABASE_URL, CORS, auth, AI, Polar, Turso, and MySQL drizzle wiring when acting as its own backend.Given the binding sets are now effectively identical between:
web(Next.js)web(TanStackStart)server(Worker at lines 221–257)you might consider extracting a Handlebars partial or helper for the shared binding body to avoid three copies of the same conditional tree. That would make future changes to secrets or DB wiring less error-prone.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (48)
apps/cli/src/constants.ts(1 hunks)apps/cli/src/helpers/core/create-readme.ts(2 hunks)apps/cli/src/helpers/core/db-setup.ts(2 hunks)apps/cli/src/helpers/core/env-setup.ts(0 hunks)apps/cli/src/helpers/core/post-installation.ts(3 hunks)apps/cli/src/helpers/core/template-manager.ts(2 hunks)apps/cli/src/helpers/database-providers/d1-setup.ts(1 hunks)apps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.ts(1 hunks)apps/cli/src/helpers/deployment/server-deploy-setup.ts(2 hunks)apps/cli/src/helpers/deployment/web-deploy-setup.ts(3 hunks)apps/cli/src/helpers/deployment/workers/workers-next-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-nuxt-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-svelte-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-tanstack-start-setup.ts(0 hunks)apps/cli/src/helpers/deployment/workers/workers-vite-setup.ts(0 hunks)apps/cli/src/prompts/server-deploy.ts(3 hunks)apps/cli/src/prompts/web-deploy.ts(1 hunks)apps/cli/src/types.ts(1 hunks)apps/cli/src/utils/config-validation.ts(1 hunks)apps/cli/templates/api/orpc/server/tsconfig.json.hbs(1 hunks)apps/cli/templates/api/trpc/server/tsconfig.json.hbs(1 hunks)apps/cli/templates/auth/better-auth/server/base/tsconfig.json.hbs(1 hunks)apps/cli/templates/db/base/tsconfig.json.hbs(1 hunks)apps/cli/templates/db/drizzle/sqlite/drizzle.config.ts.hbs(0 hunks)apps/cli/templates/deploy/alchemy/alchemy.run.ts.hbs(4 hunks)apps/cli/templates/deploy/wrangler/server/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/nuxt/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/next/open-next.config.ts(0 hunks)apps/cli/templates/deploy/wrangler/web/react/next/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/react-router/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/tanstack-router/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/react/tanstack-start/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/solid/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/deploy/wrangler/web/svelte/wrangler.jsonc.hbs(0 hunks)apps/cli/templates/examples/ai/web/react/next/src/app/ai/page.tsx.hbs(2 hunks)apps/cli/templates/extras/_npmrc.hbs(1 hunks)apps/cli/templates/frontend/react/next/next.config.ts.hbs(2 hunks)apps/cli/templates/frontend/react/next/tsconfig.json.hbs(0 hunks)apps/cli/templates/packages/config/tsconfig.base.json.hbs(1 hunks)apps/cli/test/api.test.ts(2 hunks)apps/cli/test/auth.test.ts(1 hunks)apps/cli/test/backend-runtime.test.ts(2 hunks)apps/cli/test/config-package.test.ts(2 hunks)apps/cli/test/database-setup.test.ts(3 hunks)apps/cli/test/deployment.test.ts(15 hunks)apps/cli/test/frontend.test.ts(2 hunks)apps/cli/test/integration.test.ts(9 hunks)apps/web/src/lib/constant.ts(1 hunks)
💤 Files with no reviewable changes (17)
- apps/cli/templates/frontend/react/next/tsconfig.json.hbs
- apps/cli/templates/deploy/wrangler/web/react/react-router/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/react/next/open-next.config.ts
- apps/cli/templates/deploy/wrangler/server/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/react/tanstack-start/wrangler.jsonc.hbs
- apps/cli/src/helpers/deployment/workers/workers-nuxt-setup.ts
- apps/cli/templates/deploy/wrangler/web/solid/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/svelte/wrangler.jsonc.hbs
- apps/cli/src/helpers/deployment/workers/workers-vite-setup.ts
- apps/cli/src/helpers/deployment/workers/workers-next-setup.ts
- apps/cli/src/helpers/core/env-setup.ts
- apps/cli/templates/deploy/wrangler/web/react/next/wrangler.jsonc.hbs
- apps/cli/src/helpers/deployment/workers/workers-svelte-setup.ts
- apps/cli/src/helpers/deployment/workers/workers-tanstack-start-setup.ts
- apps/cli/templates/db/drizzle/sqlite/drizzle.config.ts.hbs
- apps/cli/templates/deploy/wrangler/web/react/tanstack-router/wrangler.jsonc.hbs
- apps/cli/templates/deploy/wrangler/web/nuxt/wrangler.jsonc.hbs
🚧 Files skipped from review as they are similar to previous changes (19)
- apps/cli/test/database-setup.test.ts
- apps/cli/templates/api/trpc/server/tsconfig.json.hbs
- apps/cli/src/constants.ts
- apps/cli/test/backend-runtime.test.ts
- apps/cli/src/prompts/web-deploy.ts
- apps/cli/templates/api/orpc/server/tsconfig.json.hbs
- apps/cli/test/api.test.ts
- apps/cli/src/helpers/deployment/web-deploy-setup.ts
- apps/cli/test/frontend.test.ts
- apps/cli/templates/packages/config/tsconfig.base.json.hbs
- apps/cli/src/utils/config-validation.ts
- apps/cli/src/types.ts
- apps/cli/src/helpers/deployment/alchemy/alchemy-combined-setup.ts
- apps/cli/templates/extras/_npmrc.hbs
- apps/web/src/lib/constant.ts
- apps/cli/src/helpers/core/template-manager.ts
- apps/cli/test/config-package.test.ts
- apps/cli/test/auth.test.ts
- apps/cli/src/helpers/core/create-readme.ts
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-06-08T17:57:33.083Z
Learnt from: Vijayabaskar56
Repo: AmanVarshney01/create-better-t-stack PR: 310
File: apps/cli/templates/frontend/angular/src/app.component.html:1-7
Timestamp: 2025-06-08T17:57:33.083Z
Learning: The Angular frontend template uses Tailwind CSS v4, which doesn't require a traditional tailwind.config.js configuration file.
Applied to files:
apps/cli/templates/frontend/react/next/next.config.ts.hbs
🧬 Code graph analysis (3)
apps/cli/src/helpers/core/db-setup.ts (1)
apps/cli/src/utils/add-package-deps.ts (1)
addPackageDependency(6-59)
apps/cli/src/prompts/server-deploy.ts (2)
apps/cli/src/types.ts (1)
WebDeploy(121-121)apps/cli/src/constants.ts (1)
DEFAULT_CONFIG(40-40)
apps/cli/src/helpers/core/post-installation.ts (1)
apps/cli/src/types.ts (2)
Runtime(21-21)DatabaseSetup(80-80)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (15)
apps/cli/templates/auth/better-auth/server/base/tsconfig.json.hbs (1)
8-8:composite: trueis appropriate with declarations and shared base configEnabling
compositematches the use ofdeclaration/declarationMapand is consistent with project-references setups; this looks correct post-Wrangler removal.apps/cli/templates/db/base/tsconfig.json.hbs (1)
8-8: Consistentcomposite: truefor DB package is correctSetting
compositehere aligns the DB package with the shared base and declaration emission; change looks good and consistent with other templates.apps/cli/test/deployment.test.ts (1)
64-64: LGTM! Test fixtures correctly updated to reflect Alchemy-only deployment.All test configurations have been systematically updated to replace "wrangler" with "alchemy" for both
webDeployandserverDeployoptions. The changes are mechanical and consistent with the PR objective of removing Wrangler support. The "All Deployment Options" matrix (lines 448-504) now correctly tests only "alchemy" and "none" combinations, which aligns with the narrowed deployment choices.Also applies to: 85-85, 117-117, 197-197, 224-224, 253-253, 277-277, 322-323, 343-343, 364-364, 386-386, 408-408, 429-430, 429-430, 510-511, 531-531
apps/cli/test/integration.test.ts (1)
25-26: LGTM! Integration tests correctly updated for Alchemy deployment.All integration test scenarios have been properly updated to use "alchemy" instead of "wrangler" for deployment configurations. The changes maintain correct constraints, particularly for the Cloudflare Workers runtime at line 576, which correctly requires
serverDeploy: "alchemy". These mechanical updates align perfectly with the PR's goal of making Alchemy the sole deployment path.Also applies to: 109-109, 173-173, 235-236, 258-258, 325-325, 457-457, 480-481, 576-576
apps/cli/templates/frontend/react/next/next.config.ts.hbs (1)
1-21: LGTM! Wrangler removal and Turso support correctly implemented.The changes correctly narrow the conditional logic to only support Alchemy deployment, and the addition of
serverExternalPackagesfor Turso with libsql is appropriate for Next.js bundling.apps/cli/templates/examples/ai/web/react/next/src/app/ai/page.tsx.hbs (1)
6-28: LGTM! Dynamic import correctly restricted to Alchemy deployment.The conditional logic properly restricts dynamic imports and SSR-disabled rendering to Alchemy deployments only, with static imports used for other cases.
apps/cli/src/helpers/deployment/server-deploy-setup.ts (2)
6-21: LGTM! Early exit and simplified deployment flow.The early exit at lines 11-13 correctly prevents duplicate setup when both web and server use Alchemy, and the simplified flow properly handles only the Alchemy deployment path.
23-56: LGTM! Function signature correctly simplified.The removal of the unused
_packageManagerparameter is appropriate since the function never referenced it in the implementation.apps/cli/src/prompts/server-deploy.ts (3)
12-26: LGTM! Wrangler display logic removed.The function correctly handles deployment display with Wrangler-specific logic removed.
28-50: LGTM! Auto-selection logic correctly implemented.The function now auto-selects "alchemy" for Workers runtime and returns "none" otherwise, eliminating interactive prompts and aligning with the PR's goal of making Alchemy the sole deployment path for Workers.
52-94: LGTM! Deployment selection simplified with Wrangler removed.The function correctly removes Wrangler as an option and uses the default config for initial values.
apps/cli/src/helpers/core/post-installation.ts (2)
121-129: LGTM! SQLite local server condition correctly simplified.The condition now correctly checks only for Alchemy deployments, consistent with the removal of Wrangler support.
246-254: LGTM! Parameter names reflect unused status.The renamed parameters
_runtimeand_backendcorrectly indicate they are not used within the function body.apps/cli/src/helpers/core/db-setup.ts (1)
36-36: Good refactor: webDir consolidated at file scope.Moving
webDirto the top level eliminates the need for redeclaration and makes it consistently available across both Prisma and Drizzle branches.apps/cli/templates/deploy/alchemy/alchemy.run.ts.hbs (1)
22-25: D1 imports now correctly gated for server and self-backend web deploysThe expanded condition cleanly captures both “server worker” and “web-only self backend” cases while still requiring
dbSetup === "d1", soD1Database/Execare only present when actually needed. Looks good.
| if (database === "sqlite") { | ||
| await addPackageDependency({ | ||
| dependencies: ["drizzle-orm", "@libsql/client"], | ||
| dependencies: ["drizzle-orm", "@libsql/client", "libsql"], |
There was a problem hiding this comment.
🧩 Analysis chain
Verify that both @libsql/client and libsql packages are required.
The dependency array now includes both @libsql/client and libsql. Please confirm whether both packages are necessary for libsql/Drizzle integration with SQLite, or if there's any redundancy.
🌐 Web query:
Do libsql Drizzle projects require both @libsql/client and libsql npm packages?
💡 Result:
Short answer: No — Drizzle projects using the libSQL driver only require the @libsql/client package (plus drizzle-orm/drizzle-kit as usual). The separate libsql npm package is a different libSQL JS binding and is not required by Drizzle. [1][2][3]
Sources:
- Drizzle docs (libsql driver install instructions — recommends @libsql/client). [1]
- @libsql/client npm page (client/SDK used by Drizzle). [2]
- libsql npm page (separate libSQL Node bindings / different package). [3]
Remove the libsql package from dependencies — only @libsql/client is required.
Drizzle's libSQL driver only requires @libsql/client; the separate libsql package is an unrelated libSQL JS binding and should not be included in the dependencies array at line 77.
🤖 Prompt for AI Agents
In apps/cli/src/helpers/core/db-setup.ts around line 77, the dependencies array
incorrectly includes the standalone "libsql" package; remove "libsql" so the
array only lists "drizzle-orm" and "@libsql/client". Update the dependencies
entry to delete the "libsql" string and ensure no other references to the
removed package exist in this file.
| await addPackageDependency({ | ||
| dependencies: ["@libsql/client", "libsql"], | ||
| projectDir: webDir, | ||
| }); |
There was a problem hiding this comment.
Bug: Drizzle: Inconsistent Directory Checks
For Drizzle with SQLite, webDir dependencies are added without checking if the directory exists first. The Prisma section (line 85) checks if (await fs.pathExists(webDir)) before proceeding, but the Drizzle section skips this check, potentially causing errors if apps/web doesn't exist.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (4)
apps/cli/src/helpers/core/post-installation.ts (1)
409-412: Inconsistent command prefix in web-only Alchemy deployment instructions.The Dev command uses
${runCmd} alchemy dev, but Deploy and Destroy use${runCmd} deployand${runCmd} destroy. This inconsistency will cause the Dev command to fail if the scripts are defined in package.json as"dev": "alchemy dev". All three commands should consistently use the same pattern:${runCmd} dev,${runCmd} deploy, and${runCmd} destroy.Apply this diff to fix the inconsistency:
- `${pc.bold("Deploy web with Alchemy:")}\n${pc.cyan("•")} Dev: ${`cd apps/web && ${runCmd} alchemy dev`}\n${pc.cyan("•")} Deploy: ${`cd apps/web && ${runCmd} deploy`}\n${pc.cyan("•")} Destroy: ${`cd apps/web && ${runCmd} destroy`}`, + `${pc.bold("Deploy web with Alchemy:")}\n${pc.cyan("•")} Dev: ${`cd apps/web && ${runCmd} dev`}\n${pc.cyan("•")} Deploy: ${`cd apps/web && ${runCmd} deploy`}\n${pc.cyan("•")} Destroy: ${`cd apps/web && ${runCmd} destroy`}`,apps/cli/src/helpers/core/db-setup.ts (2)
107-110: Add existence check before accessingwebDir.The code adds libsql dependencies to
webDir(lines 107-110) without checking if the directory exists, unlike the Prisma branch (line 85) which guards itswebDiraccess withif (await fs.pathExists(webDir)). Ifapps/webdoesn't exist in certain project configurations, this will causeaddPackageDependencyto fail.Apply this diff to add the missing check:
if (database === "sqlite") { await addPackageDependency({ dependencies: ["drizzle-orm", "@libsql/client", "libsql"], devDependencies: ["drizzle-kit"], projectDir: dbPackageDir, }); - await addPackageDependency({ - dependencies: ["@libsql/client", "libsql"], - projectDir: webDir, - }); + if (await fs.pathExists(webDir)) { + await addPackageDependency({ + dependencies: ["@libsql/client", "libsql"], + projectDir: webDir, + }); + } } else if (database === "postgres") {
103-103: Remove thelibsqlpackage from dependencies — only@libsql/clientis required.Drizzle's libSQL driver only requires
@libsql/client; the separatelibsqlpackage is an unrelated libSQL JS binding and should not be included. This affects both thedbPackageDirdependencies (line 103) and thewebDirdependencies (line 108).Apply this diff to remove the redundant package:
if (database === "sqlite") { await addPackageDependency({ - dependencies: ["drizzle-orm", "@libsql/client", "libsql"], + dependencies: ["drizzle-orm", "@libsql/client"], devDependencies: ["drizzle-kit"], projectDir: dbPackageDir, }); await addPackageDependency({ - dependencies: ["@libsql/client", "libsql"], + dependencies: ["@libsql/client"], projectDir: webDir, }); } else if (database === "postgres") {Also applies to: 108-108
apps/cli/templates/db/prisma/postgres/prisma/schema/schema.prisma.hbs (1)
11-13: Same workerd gating considerations as sqlite schemaThis workerd condition mirrors the sqlite template. The same caveat applies: if
runtimecan be"node"whilebackend === "self"andwebDeploy === "alchemy", bothruntime = "nodejs"andruntime = "workerd"would render.Assuming the CLI enforces
runtime === "workers"wheneverwebDeploy === "alchemy"for Workers, this is fine; otherwise you may want to align the invariants or condition.
🧹 Nitpick comments (8)
apps/cli/src/helpers/core/post-installation.ts (1)
246-254: Consider removing unused parameters.The
_runtimeand_backendparameters are prefixed with underscores, indicating they're unused. Since they don't appear to be referenced in the function body, consider removing them from the signature to reduce API surface area and improve clarity.If these parameters need to be retained for API compatibility, the current approach is acceptable.
apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs (1)
10-24: Fail fast whenDATABASE_URLis missing instead of falling back to"".Right now
url: process.env.DATABASE_URL || ""will pass an empty string if the env var isn’t set, which is likely to fail later and be harder to diagnose. A small guard would make misconfiguration obvious:-import { PrismaClient } from "../prisma/generated/client"; -import { PrismaLibSql } from "@prisma/adapter-libsql"; - -const adapter = new PrismaLibSql({ - url: process.env.DATABASE_URL || "", - {{#if (eq dbSetup "turso")}} - authToken: process.env.DATABASE_AUTH_TOKEN, - {{/if}} -}); +import { PrismaClient } from "../prisma/generated/client"; +import { PrismaLibSql } from "@prisma/adapter-libsql"; + +const databaseUrl = process.env.DATABASE_URL; +if (!databaseUrl) { + throw new Error("DATABASE_URL is not set"); +} + +const adapter = new PrismaLibSql({ + url: databaseUrl, + {{#if (eq dbSetup "turso")}} + authToken: process.env.DATABASE_AUTH_TOKEN, + {{/if}} +});This keeps the Turso branch behavior the same while giving clearer errors in misconfigured environments.
apps/cli/src/constants.ts (2)
66-74: Confirm that"dev"sentinel versions for Prisma packages are correctly handledSwitching all Prisma-related entries here to
"dev"(and adding new adapters with the same value) is fine as long as all consumers ofdependencyVersionMaptreat"dev"as a special token and never write it directly into generatedpackage.jsonfiles or feed it into semver parsing. A brief comment or central helper describing this convention would help future contributors avoid misusing these entries.Please double-check the call sites that read
dependencyVersionMapfor these keys to ensure they resolve"dev"to a real version (e.g., from the repo’s rootpackage.json) before installing or writing dependencies.
154-160: Wrangler and Cloudflare-specific deps still listed despite Wrangler support removalEven though these lines weren’t touched in this diff, keeping
wrangler,@cloudflare/vite-plugin,@opennextjs/cloudflare,nitro-cloudflare-dev,@sveltejs/adapter-cloudflare, and@cloudflare/workers-typesindependencyVersionMaplooks at odds with the PR goal of removing Wrangler-based flows. If there are no remaining templates or paths that require these packages, consider dropping them to keep the map aligned with the supported deployment surface and avoid reintroducing Wrangler-based options later.It’d be worth searching for remaining usages of
"wrangler"and these Cloudflare packages in the CLI and templates to confirm whether they’re still needed or can be safely removed.apps/cli/templates/db/prisma/sqlite/prisma/schema/schema.prisma.hbs (1)
11-13: Confirm invariants to avoid doubleruntimein generatorThe broadened condition will set
runtime = "workerd"forruntime === "workers"orbackend === "self" && webDeploy === "alchemy". If the CLI ever allowsruntime === "node"in combination withbackend === "self"andwebDeploy === "alchemy", this block and theruntime = "nodejs"block would both render, leading to tworuntimelines in the generator (last one wins but is a bit surprising).If the invariant is that
webDeploy: "alchemy"for Workers always impliesruntime: "workers", this is fine; otherwise consider tightening the condition or documenting the assumption.apps/cli/templates/db/prisma/mysql/prisma/schema/schema.prisma.hbs (1)
2-13: Runtime gating looks consistent; just confirm nonode+alchemyoverlapThe generator block now:
- Aligns fields (provider/output/moduleFormat/runtime) — no functional concern.
- Uses the same broadened condition for
runtime = "workerd"as other schemas.As with the sqlite/postgres templates, this relies on the assumption that you won’t have
runtime === "node"together withbackend === "self"andwebDeploy === "alchemy", otherwise bothruntime = "nodejs"andruntime = "workerd"will render.If that combination is impossible by design, this is fine; if not, consider tightening or documenting the condition.
Also applies to: 21-21
apps/cli/templates/db/prisma/postgres/src/index.ts.hbs (1)
1-31: Adapter-based initialization is solid; consider env loading & gating consistencyThe adapter wiring for both Workers and non-Workers looks good:
- Workers:
envfrom"cloudflare:workers"with Neon/Pg adapters.- Non-Workers: Neon/Pg adapters using
process.env.DATABASE_URL.Two small points to consider:
dotenv usage asymmetry (non-workers path)
In the Node path,dotenv.config()is only called in thedbSetup === "neon"branch; the Pg branch assumesprocess.env.DATABASE_URLis already populated elsewhere. If the generated server code does not always load.envitself, you might want to either:
- move
dotenv.config()outside thedbSetupconditional, or- clearly rely on the server entrypoint to load envs and drop dotenv here entirely.
Runtime gating vs schema workerd condition
Here you gate Workers with{{#if (eq runtime "workers")}}, whereas the Prisma schema templates treatbackend === "self" && webDeploy === "alchemy"as workerd as well. This is fine if the CLI guarantees that Alchemy Workers always setruntime = "workers", but if there’s any case ofruntime = "node"+backend = "self"+webDeploy = "alchemy", this file would go down the Node path and useprocess.envin a Workers environment.Optionally, you might also want to fail fast if
DATABASE_URLis missing instead of passing""to the adapters, to yield clearer errors.apps/cli/templates/db/prisma/mysql/src/index.ts.hbs (1)
3-6: Adapter-based PrismaClient wiring looks good; consider small robustness tweaksThe adapter-based setup for both PlanetScale and MariaDB looks correct, and exporting a single
prismainstance per template is straightforward and idiomatic. A couple of optional hardening tweaks you might consider:
- For the PlanetScale path, instead of falling back to an empty string, fail fast if
DATABASE_URLis missing so misconfiguration is caught early in dev:-const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL || "" }); +const databaseUrl = process.env.DATABASE_URL; +if (!databaseUrl) { + throw new Error("DATABASE_URL is required for PlanetScale configuration"); +} +const adapter = new PrismaPlanetScale({ url: databaseUrl });
- For the MariaDB path, explicitly pass a radix to
parseIntto avoid surprises and make intent clearer:- port: parseInt(process.env.DATABASE_PORT || "3306"), + port: parseInt(process.env.DATABASE_PORT || "3306", 10),These are non-blocking; the current implementation is otherwise sound.
Also applies to: 8-19, 22-22
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
apps/cli/src/constants.ts(3 hunks)apps/cli/src/helpers/core/db-setup.ts(2 hunks)apps/cli/src/helpers/core/post-installation.ts(4 hunks)apps/cli/templates/db/prisma/mongodb/prisma/schema/schema.prisma.hbs(1 hunks)apps/cli/templates/db/prisma/mysql/prisma.config.ts.hbs(1 hunks)apps/cli/templates/db/prisma/mysql/prisma/schema/schema.prisma.hbs(1 hunks)apps/cli/templates/db/prisma/mysql/src/index.ts.hbs(1 hunks)apps/cli/templates/db/prisma/postgres/prisma.config.ts.hbs(1 hunks)apps/cli/templates/db/prisma/postgres/prisma/schema/schema.prisma.hbs(1 hunks)apps/cli/templates/db/prisma/postgres/src/index.ts.hbs(1 hunks)apps/cli/templates/db/prisma/sqlite/prisma.config.ts.hbs(1 hunks)apps/cli/templates/db/prisma/sqlite/prisma/schema/schema.prisma.hbs(1 hunks)apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
apps/cli/src/helpers/core/db-setup.ts (1)
apps/cli/src/utils/add-package-deps.ts (1)
addPackageDependency(6-59)
apps/cli/src/helpers/core/post-installation.ts (2)
apps/cli/src/types.ts (2)
Runtime(21-21)DatabaseSetup(80-80)apps/cli/test/test-utils.ts (2)
Runtime(436-436)DatabaseSetup(445-445)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (13)
apps/cli/src/helpers/core/post-installation.ts (2)
121-129: LGTM: SQLite local server gating simplified for Alchemy-only deployment.The condition correctly shows the
db:localcommand when SQLite is used without a database setup and either server or web is deploying to Alchemy. This aligns with removing Wrangler support.
313-318: LGTM: Prisma client generation correctly gated for D1+Alchemy.The condition appropriately excludes the "Generate Prisma Client" instruction when using D1 with Alchemy deployment, since Alchemy handles D1 migrations automatically (as noted on line 271).
apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs (1)
1-8: D1 adapter wiring looks correct; just verify binding name and deps.The
PrismaD1(env.DB)→new PrismaClient({ adapter })flow is consistent and clean for the D1 setup; no logic issues here. Please just double‑check that the D1 binding is consistently namedDBin the Worker/Alchemy templates and that@prisma/adapter-d1is present in the generated dependencies for this template.apps/cli/src/helpers/core/db-setup.ts (4)
6-6: LGTM: Type import improves type safety.The addition of the
AvailableDependenciestype import enhances type safety for the dependency arrays used in the Prisma branch.
37-37: LGTM: Early path initialization improves readability.Defining
webDirearly alongsidedbPackageDirmakes the code more organized and easier to follow.
56-82: LGTM: Prisma adapter refactoring improves maintainability.The refactoring to build dependency arrays conditionally based on database type and setup is clearer and more maintainable than inline dependency lists. The adapter selections are correct:
- PlanetScale and Neon use their respective adapters
- Standard MySQL uses MariaDB adapter
- SQLite uses libsql adapter
- Standard Postgres uses pg adapter
The
webDirhandling also correctly checks for directory existence before adding dependencies.Also applies to: 85-99
45-54: The review comment references code that does not exist in the current file state.The file
apps/cli/src/helpers/core/db-setup.tsdoes not contain the code structure described. The review mentionscustomDependenciesandcustomDevDependencieswith pinned versions at lines 45-54 and 86-92, but the actual code at these locations uses standarddependenciesanddevDependenciesparameters without version pinning. Additionally, version 6.19.0 does not appear anywhere in the codebase—the default Prisma version configured inconstants.tsis^6.15.0. No MongoDB-specific version pinning to 6.19.0 occurs in the database setup logic.Likely an incorrect or invalid review comment.
apps/cli/templates/db/prisma/mongodb/prisma/schema/schema.prisma.hbs (1)
5-13: The review comment is based on code that does not exist in the codebase.The review claims line 11 contains a broadened OR condition:
(or (eq runtime "workers") (and (eq backend "self") (eq webDeploy "alchemy"))), but the actual template shows a simple equality check:{{#if (eq runtime "workers")}}.All four Prisma schema templates (MongoDB, PostgreSQL, MySQL, SQLite) contain only the basic condition. Additionally, the runtime selection blocks are logically mutually exclusive since
runtimeis a single value—only one{{#if}}block can execute regardless of syntax.Likely an incorrect or invalid review comment.
apps/cli/src/constants.ts (2)
55-57: libsql dependency entry looks consistent with the new DB storyAdding
libsql: "^0.5.22"alongside@libsql/clientaligns with the PR’s move toward libsql/Turso-style flows and keeps the map coherent; no functional issues from this change in isolation.If you haven’t already, please confirm that any templates or helpers that install
libsqlexpect the^0.5.xrange and don’t rely on older APIs.
163-165: tsdown version bump appears safe but may warrant a quick compatibility checkBumping
tsdownto^0.16.5is a straightforward dependency update and looks fine from this file’s perspective.Given this tool’s impact on build/dev flows, please confirm that the updated version behaves as expected in the generated projects (e.g., test
dev/buildscripts that rely on it).apps/cli/templates/db/prisma/postgres/prisma.config.ts.hbs (1)
2-5: defineConfig-based Prisma config looks good; verify Prisma version supportThe switch to:
import { defineConfig, env } from 'prisma/config'export default defineConfig({ schema, migrations, datasource: { url: env('DATABASE_URL') } })- Optional
dotenv.configonly whendbSetup !== "prisma-postgres"is consistent with the newer
prisma.config.tspattern and with movingdatasource.urlout of the schema.Just make sure:
- The Prisma version used in generated projects supports
'prisma/config'andenv(...).- For the
dbSetup === "prisma-postgres"path,DATABASE_URLis indeed provided by the runtime/CI and doesn’t rely on the dotenv block you’ve gated out.Also applies to: 15-23
apps/cli/templates/db/prisma/mysql/prisma.config.ts.hbs (1)
2-4: MySQL prisma.config.ts matches new pattern; confirm Prisma support and cwd assumptionsThis config mirrors the new pattern:
defineConfig/envfrom'prisma/config'.dotenv.config({ path: "../../apps/web/.env" | "../../apps/server/.env" })based on backend.datasource.urlmoved here asenv('DATABASE_URL').That all looks consistent with the other templates and with removing
urlfrom the schema.Two things to verify:
- The Prisma version in generated projects supports
'prisma/config'andenv(...).- The scripts invoking Prisma run with the expected
process.cwd()so the../../apps/.../.envpaths resolve correctly (same assumption as the previous template).Also applies to: 13-21
apps/cli/templates/db/prisma/sqlite/prisma.config.ts.hbs (1)
2-3: SQLite Prisma config template looks correct and consistentThe switch to
defineConfigwithenv("DATABASE_URL"), plus loading.envviadotenv.configbefore config creation, looks sound and aligns with the other Prisma templates described in the PR.schema/migrationspaths and the conditional.envpathing based onbackendare coherent, and there are no obvious runtime or typing pitfalls in this template.Also applies to: 11-11, 13-21
There was a problem hiding this comment.
Bug: Solid Vite: Backend Self-Configuration Fails
The Vite (Solid) web export is missing bindings for backend === "self" configurations (database, auth secrets, etc.). When using fullstack mode with Solid, environment variables required for the backend won't be passed, causing deployment and runtime failures.
apps/cli/templates/deploy/alchemy/alchemy.run.ts.hbs#L197-L209
create-better-t-stack/apps/cli/templates/deploy/alchemy/alchemy.run.ts.hbs
Lines 197 to 209 in 281ca96
| DATABASE_PASSWORD: process.env.DATABASE_PASSWORD || "", | ||
| {{/if}} | ||
| {{/if}} | ||
| {{/if}} |
There was a problem hiding this comment.
Bug: Nuxt Fullstack Backend Configuration Failure
The Nuxt web export is missing bindings for backend === "self" configurations (database, auth secrets, etc.). When using fullstack mode with Nuxt, environment variables required for the backend won't be passed, causing deployment and runtime failures.
| DATABASE_PASSWORD: process.env.DATABASE_PASSWORD || "", | ||
| {{/if}} | ||
| {{/if}} | ||
| {{/if}} |
There was a problem hiding this comment.
Bug: React Router: Fullstack Backend Configuration Incomplete
The ReactRouter web export is missing bindings for backend === "self" configurations (database, auth secrets, etc.). When using fullstack mode with React Router, environment variables required for the backend won't be passed, causing deployment and runtime failures.
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/cli/templates/api/trpc/server/package.json.hbs (1)
1-17: Add@{{projectName}}packages totranspilePackagesin the Next.js template.The Next.js template currently omits the internal packages from
transpilePackagesconfiguration. Since the package.json templates export only source TypeScript files without atypescondition, Next.js requires explicittranspilePackagesconfiguration to transpile these external.tsfiles. Without this, consuming Next.js apps will fail with TypeScript TS7016 errors when importing from@{{projectName}}/api,@{{projectName}}/db, or@{{projectName}}/auth.Other frameworks (Vite-based: React Router, Tanstack Start, Svelte, Solid; and Nuxt) handle TypeScript transpilation natively and are unaffected.
Fix: In
apps/cli/templates/frontend/react/next/next.config.ts.hbs, add the internal packages totranspilePackages:transpilePackages: [ "shiki", "@{{projectName}}/api", "@{{projectName}}/db", "@{{projectName}}/auth" ],
♻️ Duplicate comments (3)
apps/cli/templates/db/base/package.json.hbs (1)
1-17: Covered by consolidated review comment.This file exhibits the same pattern as the consolidated review comment for
apps/cli/templates/api/trpc/server/package.json.hbs. Please refer to that comment for verification steps.apps/cli/templates/api/orpc/server/package.json.hbs (1)
1-18: Covered by consolidated review comment.This file exhibits the same pattern as the consolidated review comment for
apps/cli/templates/api/trpc/server/package.json.hbs. Please refer to that comment for verification steps.apps/cli/templates/auth/better-auth/server/base/package.json.hbs (1)
1-17: Covered by consolidated review comment.This file exhibits the same pattern as the consolidated review comment for
apps/cli/templates/api/trpc/server/package.json.hbs. Please refer to that comment for verification steps.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
apps/cli/src/helpers/core/workspace-setup.ts(2 hunks)apps/cli/templates/api/orpc/server/package.json.hbs(1 hunks)apps/cli/templates/api/orpc/server/tsdown.config.ts.hbs(0 hunks)apps/cli/templates/api/trpc/server/package.json.hbs(1 hunks)apps/cli/templates/api/trpc/server/tsdown.config.ts.hbs(0 hunks)apps/cli/templates/auth/better-auth/server/base/package.json.hbs(1 hunks)apps/cli/templates/auth/better-auth/server/base/tsdown.config.ts.hbs(0 hunks)apps/cli/templates/db/base/package.json.hbs(1 hunks)apps/cli/templates/db/base/tsdown.config.ts.hbs(0 hunks)apps/cli/templates/db/prisma/mysql/src/index.ts.hbs(1 hunks)
💤 Files with no reviewable changes (4)
- apps/cli/templates/db/base/tsdown.config.ts.hbs
- apps/cli/templates/api/orpc/server/tsdown.config.ts.hbs
- apps/cli/templates/api/trpc/server/tsdown.config.ts.hbs
- apps/cli/templates/auth/better-auth/server/base/tsdown.config.ts.hbs
🧰 Additional context used
🧬 Code graph analysis (1)
apps/cli/src/helpers/core/workspace-setup.ts (1)
apps/cli/src/constants.ts (1)
AvailableDependencies(172-172)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (1)
apps/cli/src/helpers/core/workspace-setup.ts (1)
16-16: Scopingtsdownto server package only is a good refactor.The change removes
tsdownas a shared dev dependency and scopes it exclusively to the server package in generated projects. This aligns with the PR's consolidation objectives and doesn't break the actual codebase—apps/cliitself retainstsdownin its own dependencies and build scripts.
| const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL || "" }); | ||
| const prisma = new PrismaClient({ adapter }); |
There was a problem hiding this comment.
Validate DATABASE_URL for Planetscale adapter.
The fallback to an empty string (process.env.DATABASE_URL || "") will likely cause the Planetscale adapter to fail during initialization or first query. Validate that DATABASE_URL is set and provide a clear error message, consistent with the MariaDB path.
Apply this diff to add validation:
-const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL || "" });
+const databaseUrl = process.env.DATABASE_URL;
+if (!databaseUrl) {
+ throw new Error("DATABASE_URL environment variable is required for Planetscale connection");
+}
+
+const adapter = new PrismaPlanetScale({ url: databaseUrl });
const prisma = new PrismaClient({ adapter });📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const adapter = new PrismaPlanetScale({ url: process.env.DATABASE_URL || "" }); | |
| const prisma = new PrismaClient({ adapter }); | |
| const databaseUrl = process.env.DATABASE_URL; | |
| if (!databaseUrl) { | |
| throw new Error("DATABASE_URL environment variable is required for Planetscale connection"); | |
| } | |
| const adapter = new PrismaPlanetScale({ url: databaseUrl }); | |
| const prisma = new PrismaClient({ adapter }); |
🤖 Prompt for AI Agents
In apps/cli/templates/db/prisma/mysql/src/index.ts.hbs around lines 6 to 7, the
code currently falls back to an empty string for process.env.DATABASE_URL which
will break the PrismaPlanetScale adapter; replace that with a validation: check
if process.env.DATABASE_URL is present and non-empty, and if not throw or log a
clear error and exit (matching the MariaDB path behavior), otherwise pass the
validated URL into new PrismaPlanetScale and into PrismaClient.
| const databaseUrl: string = process.env.DATABASE_URL!; | ||
|
|
||
| const url: URL = new URL(databaseUrl); |
There was a problem hiding this comment.
Add validation and error handling for DATABASE_URL.
The non-null assertion on line 11 will cause a runtime crash if DATABASE_URL is not set, and the URL constructor on line 13 will throw with a cryptic error for malformed URLs. Add validation with clear error messages to help developers debug configuration issues.
Apply this diff to add validation:
-const databaseUrl: string = process.env.DATABASE_URL!;
-
-const url: URL = new URL(databaseUrl);
+const databaseUrl = process.env.DATABASE_URL;
+if (!databaseUrl) {
+ throw new Error("DATABASE_URL environment variable is required for MariaDB connection");
+}
+
+let url: URL;
+try {
+ url = new URL(databaseUrl);
+} catch (error) {
+ throw new Error(`Invalid DATABASE_URL format: ${error instanceof Error ? error.message : String(error)}`);
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const databaseUrl: string = process.env.DATABASE_URL!; | |
| const url: URL = new URL(databaseUrl); | |
| const databaseUrl = process.env.DATABASE_URL; | |
| if (!databaseUrl) { | |
| throw new Error("DATABASE_URL environment variable is required for MariaDB connection"); | |
| } | |
| let url: URL; | |
| try { | |
| url = new URL(databaseUrl); | |
| } catch (error) { | |
| throw new Error(`Invalid DATABASE_URL format: ${error instanceof Error ? error.message : String(error)}`); | |
| } |
🤖 Prompt for AI Agents
In apps/cli/templates/db/prisma/mysql/src/index.ts.hbs around lines 11 to 13,
the code uses a non-null assertion for process.env.DATABASE_URL and passes it
directly to new URL(), which will crash with unclear errors if the env var is
missing or malformed; replace the non-null assertion with explicit validation:
check if process.env.DATABASE_URL is present and throw a clear, descriptive
Error if not, then attempt to construct a URL inside a try/catch block and throw
a new Error with a helpful message if the URL constructor fails (include the
original error message or the invalid value) so configuration issues surface
with actionable diagnostics.
| const connectionConfig = { | ||
| host: url.hostname, | ||
| port: parseInt(url.port || "3306"), | ||
| user: url.username, | ||
| password: url.password, | ||
| database: url.pathname.slice(1), | ||
| }; |
There was a problem hiding this comment.
Validate extracted database name.
If the DATABASE_URL pathname is just "/" (missing database name), url.pathname.slice(1) will produce an empty string, causing connection failures. Add validation to ensure the database name is present.
Apply this diff to validate the database name:
const url: URL = new URL(databaseUrl);
+
+const databaseName = url.pathname.slice(1);
+if (!databaseName) {
+ throw new Error("DATABASE_URL must include a database name in the path (e.g., mysql://host:port/database_name)");
+}
+
const connectionConfig = {
host: url.hostname,
port: parseInt(url.port || "3306"),
user: url.username,
password: url.password,
- database: url.pathname.slice(1),
+ database: databaseName,
};Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In apps/cli/templates/db/prisma/mysql/src/index.ts.hbs around lines 14 to 20,
the database name is extracted with url.pathname.slice(1) but not validated; if
pathname === "/" this yields an empty string and causes connection failures.
Update the code to check that the extracted database name is non-empty (trimmed)
and throw or log a clear error (or exit) when missing, otherwise assign the
validated name to connectionConfig.database; ensure the error message references
DATABASE_URL and suggests the expected format (e.g.
mysql://user:pass@host:port/dbname).
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
apps/cli/src/helpers/core/db-setup.ts (2)
108-108: Remove unnecessarylibsqlpackage.The
libsqlpackage is redundant; Drizzle's libSQL driver only requires@libsql/client. The separatelibsqlpackage is an unrelated binding and should be removed from both the db package and web dependencies.
112-115: Add missing existence check forwebDir.The code unconditionally adds dependencies to
webDirwithout checking if the directory exists, unlike the Prisma branch (line 90) which guards withif (await fs.pathExists(webDir)). Ifapps/webdoesn't exist, this will causeaddPackageDependencyto fail.Apply this diff to add the missing check:
if (database === "sqlite") { await addPackageDependency({ dependencies: ["drizzle-orm", "@libsql/client", "libsql"], devDependencies: ["drizzle-kit"], projectDir: dbPackageDir, }); - await addPackageDependency({ - dependencies: ["@libsql/client", "libsql"], - projectDir: webDir, - }); + if (await fs.pathExists(webDir)) { + await addPackageDependency({ + dependencies: ["@libsql/client", "libsql"], + projectDir: webDir, + }); + } } else if (database === "postgres") {
🧹 Nitpick comments (3)
apps/cli/templates/db/prisma/postgres/src/index.ts.hbs (3)
1-24: Consider validating DATABASE_URL before adapter initialization.All adapter initializations use
env.DATABASE_URL || ""as a fallback. An empty connection string will likely cause a runtime error when Prisma attempts to establish a connection. Consider throwing a descriptive error ifDATABASE_URLis undefined.Example for both branches:
+if (!env.DATABASE_URL) { + throw new Error("DATABASE_URL environment variable is required"); +} + const prisma = new PrismaClient({ adapter: new PrismaNeon({ - connectionString: env.DATABASE_URL || "", + connectionString: env.DATABASE_URL, }), });
25-50: Consider validating DATABASE_URL before adapter initialization.Similar to the workers branch, the fallback to an empty string (
process.env.DATABASE_URL || "") will likely cause runtime connection errors. Validate the environment variable before creating the adapter.Example for both branches:
+if (!process.env.DATABASE_URL) { + throw new Error("DATABASE_URL environment variable is required"); +} + -const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL || "" }); +const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL }); const prisma = new PrismaClient({ adapter });
10-21: Consider consistent adapter initialization style.The workers+neon branch creates the adapter inline (lines 10-14), while the workers+non-neon branch uses a separate variable (line 19). For consistency with the rest of the file and improved readability, consider extracting the adapter to a variable in the neon branch as well.
-const prisma = new PrismaClient({ - adapter: new PrismaNeon({ - connectionString: env.DATABASE_URL || "", - }), -}); +const adapter = new PrismaNeon({ + connectionString: env.DATABASE_URL || "", +}); +const prisma = new PrismaClient({ adapter });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
apps/cli/src/constants.ts(2 hunks)apps/cli/src/helpers/core/db-setup.ts(2 hunks)apps/cli/templates/db/prisma/postgres/src/index.ts.hbs(1 hunks)apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
apps/cli/src/helpers/core/db-setup.ts (2)
apps/cli/src/utils/add-package-deps.ts (1)
addPackageDependency(6-59)apps/cli/src/constants.ts (1)
AvailableDependencies(172-172)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (10)
apps/cli/templates/db/prisma/postgres/src/index.ts.hbs (1)
1-50: Adapter-based Prisma initialization looks good.The runtime-specific branching and adapter selection logic is correct. The use of
PrismaNeonfor Neon databases andPrismaPgfor other PostgreSQL setups is appropriate, and the environment-specific configurations (cloudflare:workers env vs process.env, Neon's ws setup for Node.js) are properly handled.apps/cli/src/helpers/core/db-setup.ts (5)
6-6: LGTM: Type import enhances type safety.The type import for
AvailableDependenciesproperly types the computed dependency arrays below and ensures compile-time validation against the version map.
37-37: LGTM: Early initialization improves readability.Defining
webDironce at the top reduces duplication and makes the code more maintainable.
56-88: LGTM: Clean adapter resolution logic.The computed dependency arrays correctly handle adapter selection for different database types and providers, with proper separation between runtime dependencies and dev dependencies.
90-104: LGTM: Proper existence check for web directory.The Prisma branch correctly guards
webDiraccess with an existence check and handles both MongoDB's custom version and standard@prisma/clientfor other databases.
45-54: Prisma 6.19.0 is confirmed compatible with MongoDB.Prisma v6.19.0 supports MongoDB with Prisma Client working with MongoDB. The version pinning in your code is valid and appropriate for MongoDB configurations.
apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs (1)
3-7: D1 adapter +cloudflare:workersenv usage looks correctThe
PrismaD1adapter wiring withenv.DBmatches current Prisma D1 examples, and importingenvfrom"cloudflare:workers"is consistent with workerd/Workers-style runtimes. No changes needed here; just ensure your deployment config actually binds the D1 database asDBso this stays in sync.apps/cli/src/constants.ts (3)
58-58: LGTM: Neon serverless patch bump.The patch version bump from
^1.0.1to^1.0.2is appropriate and should contain bug fixes without breaking changes.
56-56: LGTM: libsql dependency added with current stable version.The latest stable libsql npm package version is 0.5.22, matching the
^0.5.22specified in the code. The addition aligns with the PR's migration of SQLite handling toward libsql and Alchemy-based flows.
164-164: tsdown version bump is safe — no breaking changes between 0.15.5 and 0.16.5.tsdown v0.16.5 release notes list only features and bug fixes with no breaking changes. The update is safe to proceed with.
| import { PrismaLibSql } from "@prisma/adapter-libsql"; | ||
|
|
||
| const adapter = new PrismaLibSQL({ | ||
| url: process.env.DATABASE_URL || "", | ||
| authToken: process.env.DATABASE_AUTH_TOKEN, | ||
| const adapter = new PrismaLibSql({ | ||
| url: process.env.DATABASE_URL || "", | ||
| {{#if (eq dbSetup "turso")}} | ||
| authToken: process.env.DATABASE_AUTH_TOKEN, | ||
| {{/if}} |
There was a problem hiding this comment.
🧩 Analysis chain
Fix PrismaLibSQL class name import — current code will break at runtime
@prisma/adapter-libsql exports PrismaLibSQL (with SQL capitalized). Importing PrismaLibSql will be undefined, so new PrismaLibSql(...) will throw when this template is instantiated.
Recommend adjusting both the import and constructor usage:
-import { PrismaLibSql } from "@prisma/adapter-libsql";
+import { PrismaLibSQL } from "@prisma/adapter-libsql";
-const adapter = new PrismaLibSql({
+const adapter = new PrismaLibSQL({
url: process.env.DATABASE_URL || "",
{{#if (eq dbSetup "turso")}}
authToken: process.env.DATABASE_AUTH_TOKEN,
{{/if}}
});Additionally, this branch relies on process.env.*; if this template is ever used in a pure Workers/runtime context (without Node-style env injection), you’ll need to ensure your bundler or runtime provides those env vars, or switch to the same cloudflare:workers env pattern used in the D1 branch.
🌐 Web query:
Confirm the current exported class name from `@prisma/adapter-libsql` in the official Prisma docs and whether any recent versions renamed `PrismaLibSQL`.
💡 Result:
The package exports a class named PrismaLibSQL. Documentation examples in the official Prisma docs and the package README/import guidance use "PrismaLibSQL" (e.g., import { PrismaLibSQL } from '@prisma/adapter-libsql'). [1][2][3]
I found no evidence in Prisma's docs or the package README/changelog that recent versions renamed PrismaLibSQL (checked Prisma docs and the npm package info as of Nov 19, 2025). [1][2][3]
Sources:
[1] Prisma docs — Turso / libSQL adapter examples (shows import { PrismaLibSQL } ...).
[2] Prisma docs — Database drivers / adapter examples (shows PrismaLibSQL usage).
[3] npm package @prisma/adapter-libsql README (package usage showing PrismaLibSQL).
Fix PrismaLibSQL class name import — current code will break at runtime
The official Prisma documentation confirms the correct export is PrismaLibSQL (capital SQL). The current import of PrismaLibSql (lowercase 's') will be undefined, causing new PrismaLibSql(...) to throw at runtime.
Update both the import and constructor at lines 12 and 15:
-import { PrismaLibSql } from "@prisma/adapter-libsql";
+import { PrismaLibSQL } from "@prisma/adapter-libsql";
-const adapter = new PrismaLibSql({
+const adapter = new PrismaLibSQL({
url: process.env.DATABASE_URL || "",
{{#if (eq dbSetup "turso")}}
authToken: process.env.DATABASE_AUTH_TOKEN,
{{/if}}
});Additionally, consider whether process.env.* access works in your deployment context; if this template may be used in a Workers environment without Node-style env injection, ensure your bundler or runtime provides these variables or align with the pattern used in the D1 branch.
🤖 Prompt for AI Agents
In apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs around lines 12 to 18,
the import and constructor use the wrong identifier PrismaLibSql (lowercase 's')
which will be undefined at runtime; change both the import and the new
expression to PrismaLibSQL (capital 'SQL') so the exported class is referenced
correctly, and while editing confirm that process.env.DATABASE_URL and
DATABASE_AUTH_TOKEN are available in your target runtime or replace with the
equivalent configuration mechanism used for Workers/D1 if needed.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (5)
apps/cli/src/helpers/core/post-installation.ts (1)
419-419: Command prefix inconsistency in web-only Alchemy deployment.The Dev command uses
cd apps/web && ${runCmd} alchemy dev, but Deploy and Destroy usecd apps/web && ${runCmd} deploy/destroywithout thealchemyprefix. This is inconsistent with:
- Line 427 (server-only): uses
${runCmd} dev(noalchemyprefix)- Line 434 (combined): uses
${runCmd} dev(noalchemyprefix)All three deployment scenarios should use consistent command patterns.
Verify the correct command format by checking how scripts are defined in the package.json files:
#!/bin/bash # Check how alchemy commands are defined in package.json files echo "=== Root package.json scripts ===" fd -t f '^package\.json$' --max-depth 1 --exec jq '.scripts | with_entries(select(.key | test("dev|deploy|destroy|alchemy")))' {} \; echo -e "\n=== apps/web/package.json scripts ===" fd -t f '^package\.json$' apps/web --max-depth 1 --exec jq '.scripts | with_entries(select(.key | test("dev|deploy|destroy|alchemy")))' {} \; echo -e "\n=== apps/server/package.json scripts ===" fd -t f '^package\.json$' apps/server --max-depth 1 --exec jq '.scripts | with_entries(select(.key | test("dev|deploy|destroy|alchemy")))' {} \;Based on the results, either:
- Remove
alchemyprefix from line 419:${runCmd} devinstead of${runCmd} alchemy dev- Or add
alchemyprefix to all commands consistently across lines 419, 427, and 434apps/cli/templates/db/prisma/mysql/src/index.ts.hbs (1)
5-9: Avoid|| ""fallback and validateenv.DATABASE_URLfor Planetscale (workers).Falling back to an empty string will cause the Planetscale adapter to fail with unclear errors when
DATABASE_URLis missing. Validate presence and pass the validated value into the adapter.-const adapter = new PrismaPlanetScale({ url: env.DATABASE_URL || "" }); -const prisma = new PrismaClient({ adapter }); +const databaseUrl = env.DATABASE_URL; +if (!databaseUrl) { + throw new Error("DATABASE_URL environment variable is required for Planetscale connection"); +} + +const adapter = new PrismaPlanetScale({ url: databaseUrl }); +const prisma = new PrismaClient({ adapter });Please double‑check against the latest
@prisma/adapter-planetscaledocs to ensure this configuration matches the expected options.apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs (1)
12-28: FixPrismaLibSQLclass name — current adapter reference will be undefined at runtime
@prisma/adapter-libsqlexportsPrismaLibSQL(capital “SQL”). Importing/instantiatingPrismaLibSql(lowercase “s”) will beundefined, sonew PrismaLibSql(...)will throw when this template is instantiated. This was already flagged on a previous revision and still needs to be corrected.Suggested fix:
-{{else}} -import { PrismaLibSql } from "@prisma/adapter-libsql"; +{{else}} +import { PrismaLibSQL } from "@prisma/adapter-libsql"; {{#if (eq runtime "workers")}} import { env } from "cloudflare:workers"; {{/if}} -const adapter = new PrismaLibSql({ +const adapter = new PrismaLibSQL({ url: {{#if (eq runtime "workers")}}env.DATABASE_URL || ""{{else}}process.env.DATABASE_URL || ""{{/if}}, {{#if (eq dbSetup "turso")}} authToken: {{#if (eq runtime "workers")}}env.DATABASE_AUTH_TOKEN || ""{{else}}process.env.DATABASE_AUTH_TOKEN || ""{{/if}}, {{/if}} });Optionally, you might also consider dropping the
|| ""defaults so missingDATABASE_URL(orDATABASE_AUTH_TOKENfor Turso) fails fast instead of silently passing an empty string.apps/cli/src/helpers/core/db-setup.ts (2)
112-113: Re‑validate that both@libsql/clientandlibsqlare needed for Drizzle + SQLite.You’re now installing both
@libsql/clientandlibsqlin the db package and propagating them toapps/web. Earlier analysis (based on Drizzle/libSQL docs) suggested that typical Drizzle + libSQL setups only require@libsql/client, withlibsqlbeing a separate Node binding that isn’t strictly necessary for HTTP‑based drivers. If the templates or runtime wiring really do use both packages (e.g. one for local file access, one for remote/Turso), this is fine; otherwise you may want to droplibsqlto keep the dependency surface smaller.Can you confirm that
libsqlis explicitly imported/used somewhere in the generated code paths for Drizzle + SQLite, and not just added speculatively?#!/bin/bash # Check where `libsql` is actually used in the repo to confirm it is required. rg -n "\blibsql\b" -C3Also applies to: 117-118
37-37: Guard Drizzle SQLite web dependencies with an existence check forapps/web.In the Drizzle + SQLite branch you unconditionally call
addPackageDependencytargetingwebDir, unlike the Prisma branch which first checksawait fs.pathExists(webDir). If a template doesn’t generateapps/web, this will attempt to read a non‑existentpackage.jsonand fail. This is the same issue previously flagged on this file for the Drizzle branch.Apply a guard consistent with the Prisma logic:
if (database === "sqlite") { await addPackageDependency({ dependencies: ["drizzle-orm", "@libsql/client", "libsql"], devDependencies: ["drizzle-kit"], projectDir: dbPackageDir, }); - await addPackageDependency({ - dependencies: ["@libsql/client", "libsql"], - projectDir: webDir, - }); + if (await fs.pathExists(webDir)) { + await addPackageDependency({ + dependencies: ["@libsql/client", "libsql"], + projectDir: webDir, + }); + } } else if (database === "postgres") {Also applies to: 116-119
🧹 Nitpick comments (1)
apps/cli/src/helpers/core/db-setup.ts (1)
45-55: Consolidate the hardcoded MongoDB Prisma version "6.19.0" withindb-setup.ts.The version string appears 3 times in apps/cli/src/helpers/core/db-setup.ts (lines 48, 51, 98), all within the MongoDB configuration blocks. While they're in the same file rather than separate packages, extracting this to a named constant at the top of the file would make future version bumps simpler and reduce the risk of drift.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
apps/cli/src/constants.ts(2 hunks)apps/cli/src/helpers/core/db-setup.ts(2 hunks)apps/cli/src/helpers/core/post-installation.ts(5 hunks)apps/cli/templates/db/prisma/mysql/src/index.ts.hbs(1 hunks)apps/cli/templates/db/prisma/postgres/prisma.config.ts.hbs(1 hunks)apps/cli/templates/db/prisma/sqlite/prisma.config.ts.hbs(1 hunks)apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/cli/templates/db/prisma/sqlite/prisma.config.ts.hbs
🧰 Additional context used
🧬 Code graph analysis (2)
apps/cli/src/helpers/core/post-installation.ts (3)
apps/cli/src/types.ts (2)
Runtime(21-21)DatabaseSetup(80-80)apps/cli/test/test-utils.ts (2)
Runtime(436-436)DatabaseSetup(445-445)apps/cli/src/index.ts (2)
Runtime(256-256)DatabaseSetup(261-261)
apps/cli/src/helpers/core/db-setup.ts (2)
apps/cli/src/utils/add-package-deps.ts (1)
addPackageDependency(6-59)apps/cli/src/constants.ts (1)
AvailableDependencies(172-172)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Cursor Bugbot
🔇 Additional comments (11)
apps/cli/src/helpers/core/post-installation.ts (3)
121-129: LGTM! SQLite local server gating updated correctly.The condition now appropriately triggers the local SQLite server instruction only when deploying with Alchemy, aligning with the removal of Wrangler support.
300-306: LGTM! Helpful Turso + Prisma guidance added.The new instructions provide users with a clear reference to Turso's Prisma migration guide when using this combination, which is helpful for setup.
321-326: LGTM! Prisma client generation correctly gated.The conditional logic appropriately skips manual Prisma client generation instructions when using D1 with Alchemy, since migrations are handled automatically in that configuration.
apps/cli/templates/db/prisma/postgres/prisma.config.ts.hbs (3)
6-12: LGTM!The conditional dotenv configuration correctly loads environment variables from the appropriate location based on the backend type.
2-2: ****The import of
defineConfigandenvfrom 'prisma/config' is valid and part of the official Prisma configuration API. No action needed.Likely an incorrect or invalid review comment.
15-23: No issues found—this follows official Prisma configuration patterns.The
defineConfigandenv()function are legitimate exports fromprisma/configand represent the official Prisma approach for programmatic configuration. The env helper lets you access environment variables in prisma.config.ts in a type-safe way, imported viaimport { defineConfig, env } from "prisma/config". The code is correctly configured and consistent across all database templates.Likely an incorrect or invalid review comment.
apps/cli/templates/db/prisma/sqlite/src/index.ts.hbs (2)
1-1: PrismaClient import path looks reasonable but depends on generator outputImporting
PrismaClientfrom"../prisma/generated/client"matches the usual Prisma client layout; just confirm the CLI actually emits the client into this path for the SQLite/Workers combinations so this stays in sync with template generation.
3-10: D1 branch hard-depends on Workersenv— ensuredbSetup: "d1"is never used outside WorkersThe D1 path imports
envfrom"cloudflare:workers"and callsnew PrismaD1(env.DB). This is fine as long as the generator only ever selectsdbSetup === "d1"when targeting a Workers/Alchemy runtime; if a Node/Bun runtime could be combined with"d1", this import would break the build.apps/cli/src/constants.ts (2)
55-60: libsql and Neon versions – verified as correctly centralizedAll packages referenced in db-setup.ts (
@libsql/client,libsql,@neondatabase/serverless,ws,@prisma/adapter-neon, and others) are properly defined independencyVersionMapand correctly resolved byaddPackageDependency(). No hard-coded version strings exist outsideconstants.ts. The versions are properly centralized.
154-159: I need to verify whether Alchemy deployment support is also being removed in this PR. The search results show these Cloudflare dependencies are actively used in Alchemy setup files.I need to determine the exact scope of this PR to understand whether Alchemy support is also being removed.
I need to check whether the alchemy-related files are being modified or removed as part of this PR.Based on my verification, I now have enough information to determine whether the review comment is correct. Let me search for any remaining alchemy-related files to see if they're still active:Based on my extensive verification, I now have sufficient information to generate the rewritten review comment. The key findings are:
Cloudflare dependencies ARE actively used in the codebase in multiple places:
./apps/cli/src/helpers/deployment/alchemy/alchemy-*.tsfiles still actively reference and add these dependencies./apps/cli/templates/files still contain conditional Cloudflare references tied to "alchemy" deployments- These are not dead code if Alchemy deployment support still exists
The issue is unclear scope: The review comment assumes all Cloudflare deps are dead because Wrangler support is being removed, but it doesn't verify whether Alchemy deployment (which also uses these deps) is being removed.
Without definitive proof that the alchemy-* setup files are being deleted or that Alchemy support is being dropped, the review comment's suggestion to remove these dependencies is premature and potentially incorrect.
This is a case where the review comment should be because:
- The dependencies ARE in active use
- The scope of the PR (whether it removes ONLY Wrangler or also Alchemy) is unclear
- The reviewer should manually verify the PR scope and confirm whether Alchemy deployments are also being removed before removing these dependency entries
Cloudflare/Wrangler dependency entries in
dependencyVersionMapare still actively used by Alchemy deployment setup flowsThe dependencies flagged (
wrangler,@cloudflare/vite-plugin,@opennextjs/cloudflare,nitro-cloudflare-dev,@sveltejs/adapter-cloudflare,@cloudflare/workers-types) are referenced in multiple active code paths:
./apps/cli/src/helpers/deployment/alchemy/alchemy-next-setup.ts(lines 15-16, 35)./apps/cli/src/helpers/deployment/alchemy/alchemy-nuxt-setup.ts(line 16)./apps/cli/src/helpers/deployment/alchemy/alchemy-svelte-setup.ts(line 16)./apps/cli/src/helpers/deployment/alchemy/alchemy-tanstack-start-setup.ts(line 16)- Template files:
tsconfig.json.hbs,next.config.ts.hbs,next.tsconfig.json.hbsBefore removing these entries, verify whether this PR also removes Alchemy deployment support. If Alchemy deployments remain active, these dependencies are still needed.
apps/cli/src/helpers/core/db-setup.ts (1)
6-6: All Prisma adapter and dependency packages are present independencyVersionMap.Verification confirms all referenced packages exist:
- Prisma adapters: @prisma/adapter-planetscale, @prisma/adapter-mariadb, @prisma/adapter-d1, @prisma/adapter-libsql, @prisma/adapter-neon, @prisma/adapter-pg (all ^7.0.0)
- Supporting dependencies: @neondatabase/serverless, ws, @types/ws, pg, @types/pg
The Prisma dependency matrix is correctly configured and will not trigger silent skips or console warnings from
addPackageDependency.
| "@prisma/client": "^7.0.0", | ||
| prisma: "^7.0.0", | ||
| "@prisma/adapter-d1": "^7.0.0", | ||
| "@prisma/adapter-neon": "^7.0.0", | ||
| "@prisma/adapter-mariadb": "^7.0.0", | ||
| "@prisma/adapter-libsql": "^7.0.0", | ||
| "@prisma/adapter-better-sqlite3": "^7.0.0", | ||
| "@prisma/adapter-pg": "^7.0.0", | ||
| "@prisma/adapter-planetscale": "^7.0.0", |
There was a problem hiding this comment.
🧩 Analysis chain
Prisma + adapters unified on ^7.0.0 – verify no leftover dev/6.x pins
Moving @prisma/client, prisma, and all adapter packages to the same ^7.0.0 range is a solid improvement over the previous dev dist‑tags and keeps the ecosystem aligned. Please just confirm that:
- every Prisma-using template/package.json is wired through this map, and
- there are no remaining
devor^6.xPrisma version pins elsewhere.
🏁 Script executed:
#!/bin/bash
# Check for any Prisma entries not using the unified ^7.0.0 range
rg -nP '"(@prisma/[^"]+"|prisma)"\s*:\s*"' -C3 .
rg -n '"prisma":\s*"dev"' -C3 . || echo "No dev Prisma pins found"Length of output: 24
</script>
🏁 Script executed:
#!/bin/bash
# Find all package.json files in the codebase
fd -t f "package\.json$" | head -20
# Check all Prisma entries with version info
echo "=== All Prisma package entries ==="
rg -n '(@prisma/|"prisma")' package.json -A1 -B1
# Specifically check for any 6.x versions
echo "=== Checking for 6.x versions ==="
rg -n '\^6\.' package.json || echo "No ^6.x found"
rg -n '6\.x' package.json || echo "No 6.x pattern found"Length of output: 223
🏁 Script executed:
#!/bin/bash
# Find all package.json files and check for Prisma entries
echo "=== All package.json files in repo ==="
find . -name "package.json" -type f | head -30
echo ""
echo "=== Prisma entries in ALL package.json files ==="
find . -name "package.json" -type f -exec grep -l '@prisma\|"prisma"' {} \;
echo ""
echo "=== Check for any version pins that are NOT ^7.0.0 ==="
find . -name "package.json" -type f -exec grep -H '@prisma/\|"prisma"' {} \; | grep -v '\^7\.0\.0'
echo ""
echo "=== Verify constants.ts has the map ==="
cat apps/cli/src/constants.ts | grep -A 15 '@prisma'Length of output: 1012
</script>
🏁 Script executed:
#!/bin/bash
# Get the actual Prisma version lines from the two package.json files with Prisma deps
echo "=== apps/cli/package.json - full Prisma section ==="
cat apps/cli/package.json | grep -A 2 -B 2 '"prisma"' | head -20
echo ""
echo "=== packages/create-bts/package.json - full Prisma section ==="
cat packages/create-bts/package.json | grep -A 2 -B 2 '"prisma"' | head -20
echo ""
echo "=== Check if packages/create-bts uses constants.ts ==="
grep -r "constants" packages/create-bts/ --include="*.ts" --include="*.js" --include="*.json" | head -10
echo ""
echo "=== Check if apps/cli/package.json references constants ==="
grep -r "constants" apps/cli/ --include="*.ts" --include="*.js" | grep -i prisma | head -10Length of output: 382
</script>
🏁 Script executed:
#!/bin/bash
# View full package.json files to see the actual structure
echo "=== apps/cli/package.json full content ==="
cat apps/cli/package.json
echo ""
echo "=== packages/create-bts/package.json full content ==="
cat packages/create-bts/package.jsonLength of output: 3388
</script>
🏁 Script executed:
#!/bin/bash
# Find where constants.ts is imported and used
echo "=== Search for constants.ts imports ==="
rg -n "from.*constants|import.*constants" apps/cli/src/ --type ts -C 2
echo ""
echo "=== Find template directories ==="
find apps/cli/templates -type f -name "*.json" 2>/dev/null | head -20
echo ""
echo "=== Check if templates contain package.json files ==="
find apps/cli/templates -name "package.json" 2>/dev/null
echo ""
echo "=== Check for any hardcoded Prisma versions in src files ==="
rg -n 'prisma|@prisma' apps/cli/src/ --type ts | grep -i versionLength of output: 9338
</script>
🏁 Script executed:
#!/bin/bash
# View the add-package-deps.ts implementation to verify it uses dependencyVersionMap
echo "=== add-package-deps.ts implementation ==="
cat apps/cli/src/utils/add-package-deps.ts
echo ""
echo "=== Search for any other Prisma version definitions ==="
rg -n '@prisma|prisma.*version|version.*prisma' apps/cli/src --type ts -i | grep -v node_modules
echo ""
echo "=== Verify dependencyVersionMap export in constants.ts ==="
cat apps/cli/src/constants.ts | head -100Length of output: 5683
</script>
🏁 Script executed:
#!/bin/bash
# View the context around the hardcoded Prisma 6.19.0 versions
echo "=== db-setup.ts lines 40-60 ==="
sed -n '40,60p' apps/cli/src/helpers/core/db-setup.ts
echo ""
echo "=== db-setup.ts lines 90-110 ==="
sed -n '90,110p' apps/cli/src/helpers/core/db-setup.ts
echo ""
echo "=== Full context of db-setup.ts to understand the pattern ==="
wc -l apps/cli/src/helpers/core/db-setup.tsLength of output: 1161
Prisma 6.19.0 hardcoded for MongoDB – breaks unified ^7.0.0 alignment
Verification found hardcoded "@prisma/client": "6.19.0" and prisma: "6.19.0" pins in apps/cli/src/helpers/core/db-setup.ts (lines 48–51 for backend, 98–102 for web) that bypass the unified ^7.0.0 map in dependencyVersionMap. This means MongoDB + Prisma projects will receive version 6.19.0 instead of 7.0.0, breaking the stated alignment.
Update these to use the map via dependencies: ["@prisma/client"] and devDependencies: ["prisma"] instead of customDependencies.
| alchemy: "^0.77.0", | ||
|
|
||
| dotenv: "^17.2.2", | ||
| tsdown: "^0.15.5", | ||
| tsdown: "^0.16.5", | ||
| zod: "^4.1.11", |
There was a problem hiding this comment.
🧩 Analysis chain
tsdown bump to ^0.16.5 – ensure all configs and templates are aligned
Bumping tsdown to ^0.16.5 matches the PR summary; just double‑check that:
- all tsdown configs in generated projects are compatible with this version, and
- you don’t have any template/package.json still pinning an older tsdown (especially now that it’s meant to live only in the server app).
🏁 Script executed:
#!/bin/bash
# Audit tsdown usage and versions across the repo
rg -n 'tsdown' -C3 .Length of output: 5011
Update apps/cli/package.json to match the tsdown bump
The CLI app's own package.json still pins tsdown to ^0.15.9 while src/constants.ts was updated to ^0.16.5. This creates a mismatch: generated projects will use 0.16.5, but the CLI itself remains on 0.15.9.
Update apps/cli/package.json line 91 from "tsdown": "^0.15.9" to "tsdown": "^0.16.5" and regenerate bun.lock.
🤖 Prompt for AI Agents
In apps/cli/package.json around line 91, the tsdown dependency is still pinned
to "^0.15.9" while src/constants.ts was updated to "^0.16.5"; change the tsdown
entry at line 91 to "tsdown": "^0.16.5" and then regenerate the lockfile (run
your bun install or equivalent to update bun.lock) so the CLI package and
generated projects use the same tsdown version.
| dependencies: ["@prisma/client"], | ||
| projectDir: webDir, | ||
| }); | ||
| } |
There was a problem hiding this comment.
Bug: Prisma MongoDB hardcoded to v6.19.0 instead of v7.0.0
The code hardcodes Prisma and @prisma/client to version 6.19.0 when setting up MongoDB projects (lines 48-49 and 98-99), but the dependencyVersionMap in constants.ts specifies version ^7.0.0 for all Prisma packages. This creates a version mismatch where MongoDB projects will use an older Prisma version than all other database configurations, causing inconsistency and potential compatibility issues. All Prisma packages including MongoDB should use ^7.0.0 to align with the PR's Prisma 7 support goal.
Note
Removes Wrangler in favor of Alchemy-only deploy across CLI/templates/tests and upgrades Prisma to v7 with new adapter logic, plus assorted DB/env/template tweaks.
wranglersupport end-to-end (prompts, validation, README/post-install, templates, setup scripts, UI constants, and tests).^7.0.0; add adapter selection ford1,neon,pg,mariadb,planetscale,libsql/SQLite, with Workers-aware templates andprisma.configviadefineConfig.libsqland add to web where needed.DATABASE_URLappropriately for Workers/Alchemy.serverExternalPackagesfor Turso; AI example dynamic import gated by Alchemy.tsdownconfigs from package templates; keeptsdownonly where required..npmrc: switch tonode-linker=isolatedfor pnpm.@neondatabase/serverless, addlibsql).Written by Cursor Bugbot for commit be56cf5. This will update automatically on new commits. Configure here.
Summary by CodeRabbit
Removed Features
Simplified Configuration
Database Updates
Templates & Tests
Chores