Add PlanetScale support

[bnziv]

Summary by CodeRabbit

• New Features

  • Added PlanetScale hosting support for MySQL and PostgreSQL across ORM and raw-SQL options.
  • Added MySQL PlanetScale option in database host selection prompts.

• Chores

  • Bumped @planetscale/database to 1.19.0.
  • Automatically adds PostgreSQL (pg) and types when PostgreSQL + PlanetScale is selected.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds PlanetScale as a database host for MySQL and PostgreSQL, generalizes Neon-specific Postgres operations, introduces Planetscale-specific query operations and driver configurations, and updates DB initialization, import resolution, package dependencies, and DB type generation to handle engine-specific PlanetScale variants.

Changes

Cohort / File(s)	Summary
Handler templates & driver mappings src/generators/db/handlerTemplates.ts	Renamed Postgres Neon-specific ops to generic postgresQueryOperations; added mysqlPlanetScaleQueryOperations; switched MySQL flows to select by auth_sub (removed reliance on lastInsertRowid/returned uid); expanded driverConfigurations with Planetscale variants for mysql/postgres (drizzle/sql).
DB initialization codegen src/generators/project/generateDBBlock.ts	Added planetscale connection entries (MySQL -> new Client(...), Postgres -> new Pool(...)); removed dynamic mode derivation for MySQL/MariaDB PlanetScale case and unified Drizzle init to mode: 'default'; updated remote Drizzle initialization for PlanetScale.
Imports & module resolution src/generators/project/generateImportsBlock.ts	Switched Planetscale import from connect to Client; expanded PostgreSQL import branches to handle neon vs planetscale vs default; refined remote-host Drizzle import/activation logic for Postgres+PlanetScale.
Interactive prompt src/questions/databaseHost.ts	Added explicit mysql branch in getDatabaseHost with none and planetscale choices, matching PostgreSQL behavior and cancel flow.
Package manifest generation src/generators/configurations/generatePackageJson.ts	Bumped @planetscale/database to 1.19.0; when engine=postgresql and host=planetscale, inject pg and @types/pg dependencies (versions added).
Database type generation src/generators/db/generateDatabaseTypes.ts	Split PlanetScale handling by engine: mysql -> PlanetScaleDatabase (planetscale-serverless), postgresql -> NodePgDatabase (node-postgres); added databaseEngine parameter to GenerateTypesProps and generateDatabaseTypes signature.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–30 minutes

• Areas to focus during review:
  • src/generators/db/handlerTemplates.ts — verify SQL changes for Planetscale and auth_sub-based selects.
  • src/generators/project/generateImportsBlock.ts & generateDBBlock.ts — confirm import/initialization permutations for neon/planetscale/default paths.
  • src/generators/db/generateDatabaseTypes.ts — ensure databaseEngine propagation and type/import correctness.
  • src/generators/configurations/generatePackageJson.ts — dependency injection condition for Postgres+PlanetScale.

Possibly related PRs

• Add databaseTypes.ts file generation #16 — touches generateDatabaseTypes.ts; likely related to engine/host split and signature change.
• Add support for Postgres + Bun SQL and Postgres Neon + Drizzle #10 — modifies Postgres query operation definitions referenced and refactored here.
• Refactor database conditionals for readability #13 — overlaps on generator files (handlerTemplates, generateDBBlock, generateImportsBlock, package JSON updates).

Suggested reviewers

• absolutejs

Poem

🐰 I hopped in code where PlanetScale grows,
Swapped Neon notes for broader flows.
MySQL and Postgres now dance in tune,
Client, Pool, and queries hum in the moon. 🥕✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title 'Add PlanetScale support' accurately summarizes the main objective: introducing PlanetScale as a new database host option across multiple database engines and configuration generators.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/planetscale

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

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)

src/generators/project/generateDBBlock.ts (1)

41-45: Critical: Update PlanetScale initialization to use Client constructor.

Line 43 uses connect({ url: ... }) but the import was changed to Client in generateImportsBlock.ts (line 85). The generated code will import Client but not connect, causing a runtime error. This remoteDrizzleInit entry is used when orm === 'drizzle' with PlanetScale (see line 77).

Apply this diff:

 const remoteDrizzleInit: Record<string, string> = {
 	neon: 'new Pool({ connectionString: getEnv("DATABASE_URL") })',
-	planetscale: 'connect({ url: getEnv("DATABASE_URL") })',
+	planetscale: 'new Client({ url: getEnv("DATABASE_URL") })',
 	turso: 'createClient({ url: getEnv("DATABASE_URL") })'
 };

🧹 Nitpick comments (1)

src/generators/db/handlerTemplates.ts (1)

422-426: Consider removing '/dist' from the import path.

Line 424 imports from @planetscale/database/dist. Importing from internal package paths like /dist can be fragile and may break with package updates. Verify that the main package export doesn't provide Client directly.

-    importLines: `import { Client } from '@planetscale/database/dist'`,
+    importLines: `import { Client } from '@planetscale/database'`,

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5cc79b1 and cec916e.

📒 Files selected for processing (4)

• src/generators/db/handlerTemplates.ts (4 hunks)
• src/generators/project/generateDBBlock.ts (2 hunks)
• src/generators/project/generateImportsBlock.ts (1 hunks)
• src/questions/databaseHost.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

src/generators/project/generateImportsBlock.ts (1)

src/generators/db/generateDatabaseTypes.ts (1)

• GenerateTypesProps (8-42)

src/questions/databaseHost.ts (1)

src/utils/abort.ts (1)

• abort (5-8)

🔇 Additional comments (6)

src/questions/databaseHost.ts (1)

7-18: LGTM! Consistent cancellation handling added.

The PostgreSQL branch now includes explicit abort handling and unified return semantics, matching the existing pattern in the MySQL and SQLite branches.

src/generators/db/handlerTemplates.ts (3)

238-253: LGTM! Improved user lookup strategy.

The change from uid-based to auth_sub-based lookup after insertion is more deterministic and aligns with the natural key for users. The insertHistory operation correctly continues to use uid since the count_history table doesn't have auth_sub.

---

294-304: LGTM! Consistent auth_sub-based lookup.

The Drizzle variant now uses auth_sub for user lookup instead of uid, matching the SQL variant's approach. Removing .$returningId() is appropriate since the subsequent query relies on auth_sub rather than the auto-generated uid.

---

310-365: No issues found — PlanetScale API usage is correct.

The code correctly uses the PlanetScale Client API. The execute() method returns an ExecutedQuery object with the expected properties: insertId (string) for INSERT operations and rows (array) for SELECT operations. All parameterized queries follow the correct pattern, and the optional result handling is appropriate.

src/generators/project/generateImportsBlock.ts (1)

83-87: LGTM! Aligned with PlanetScale Client constructor pattern.

The import change from connect to Client aligns with the updated initialization pattern in generateDBBlock.ts (line 24) which uses new Client({ url: ... }).

src/generators/project/generateDBBlock.ts (1)

80-85: LGTM! Correct special handling for MySQL/MariaDB.

The condition correctly excludes PlanetScale from the createPool path, allowing PlanetScale connections to use the general initialization path (lines 87-90). The explicit mode: 'default' for non-PlanetScale MySQL/MariaDB connections is good practice.

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

src/generators/db/handlerTemplates.ts (1)

238-253: Consider removing unused return value from insert result.

The insert operation on line 239 captures the result, but after changing the lookup to use auth_sub (line 247), the result.lastInsertRowid is no longer accessed. While functionally correct, the result variable could be removed for clarity.

Apply this diff to simplify:

-    const result = await db`
+    await db`
       INSERT INTO users (auth_sub, metadata)
       VALUES (\${authSub}, \${JSON.stringify(userIdentity)})
     `;

However, the change to use auth_sub for lookups is correct and improves consistency.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cec916e and 041e8a5.

📒 Files selected for processing (2)

• src/generators/db/handlerTemplates.ts (5 hunks)
• src/generators/project/generateDBBlock.ts (3 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• src/generators/project/generateDBBlock.ts

🔇 Additional comments (2)

src/generators/db/handlerTemplates.ts (2)

422-426: LGTM!

The PlanetScale SQL client configuration correctly maps to mysqlPlanetScaleQueryOperations and uses the proper Client type from @planetscale/database. The structure is consistent with other driver configurations.

---

409-416: PlanetScale configuration is correct and ready for use.

Drizzle ORM v0.41.0 (from devDependencies) exceeds the v0.17.5 minimum required for PlanetScale serverless support. The configuration correctly imports PlanetScaleDatabase from 'drizzle-orm/planetscale-serverless' and uses the appropriate database type. Verification found no syntax errors in mysqlDrizzleQueryOperations, which the configuration properly reuses for query operations.

Likely an incorrect or invalid review comment.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

src/generators/project/generateDBBlock.ts (1)

24-25: Planetscale connection expressions and drizzle init paths look consistent; minor cleanup possible

The new connectionMap entries and drizzle branches align with the driver configurations you added elsewhere:

• mysql + databaseHost === 'planetscale' resolves to new Client({ url: getEnv("DATABASE_URL") }), matching the Client-based handlers.
• postgresql + databaseHost === 'planetscale' resolves to new Pool({ connectionString: getEnv("DATABASE_URL") }), matching the Pool-based handlers.
• The drizzle branch now correctly:
  • Uses createPool(...); drizzle(pool, { schema, mode: 'default' }) only for mysql/mariadb when the host is not Planetscale.
  • Falls back to drizzle(${expr}, { schema }) for Planetscale and other remote drivers, which is what the Planetscale and Node‑pg drizzle adapters expect.

Two small, non‑blocking nits:

• remoteDrizzleInit.planetscale now duplicates connectionMap.mysql.planetscale and connectionMap.postgresql.planetscale never uses it; over time this object is becoming mostly redundant. You could eventually collapse everything into connectionMap to simplify the resolution logic.
• In the drizzle branch, const pool = ${expr} will bind a Client for MySQL/Planetscale; a more generic name like connection would better reflect that it’s not always an actual pool, though this is cosmetic.

Overall, behavior and generated code look correct for all covered engine/host/ORM combinations; just ensure end‑to‑end scaffolding tests cover the new Planetscale paths.

Also applies to: 30-33, 44-48, 80-96

src/generators/db/handlerTemplates.ts (1)

310-365: PlanetScale MySQL Client queries are parameterized and consistent; small unused-variable nit

The new mysqlPlanetScaleQueryOperations set looks solid:

• All queries use db.execute(sql, [params]) with ? placeholders, so they’re parameterized.
• insertHistory correctly uses result.insertId to fetch the new row by uid and has clear error messages when insert or select fails.
• User operations insert and read via auth_sub and JSON‑stringify userIdentity, matching the other non‑drizzle MySQL drivers.

One minor DX tweak: in insertUser the result variable is declared but never used. You could simplify the generated code to:

-    const result = await db.execute(
+    await db.execute(
       `INSERT INTO users (auth_sub, metadata) VALUES (?, ?)`,
       [authSub, JSON.stringify(userIdentity)]
     );

or destructure insertId if you want an extra sanity check before the follow‑up SELECT. Functionally things are fine either way.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 041e8a5 and 10f7ed9.

📒 Files selected for processing (7)

• src/generators/configurations/generatePackageJson.ts (2 hunks)
• src/generators/db/generateDatabaseTypes.ts (1 hunks)
• src/generators/db/handlerTemplates.ts (8 hunks)
• src/generators/db/scaffoldDatabase.ts (1 hunks)
• src/generators/project/generateDBBlock.ts (3 hunks)
• src/generators/project/generateImportsBlock.ts (5 hunks)
• src/questions/databaseHost.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (4)

src/generators/db/scaffoldDatabase.ts (4)

src/questions/orm.ts (1)

• databaseEngine (7-28)

src/generators/db/generateHandlers.ts (1)

• GenerateDBHandlersProps (9-28)

src/generators/db/generateDrizzleSchema.ts (1)

• GenerateSchemaProps (61-141)

src/generators/db/generateDockerContainer.ts (1)

• databaseEngine (95-127)

src/generators/project/generateImportsBlock.ts (3)

src/generators/db/generateDrizzleSchema.ts (1)

• GenerateSchemaProps (61-141)

src/generators/configurations/generateDrizzleConfig.ts (1)

• CreateDrizzleConfigProps (11-34)

src/generators/project/generateUseBlock.ts (1)

• pluginImport (15-50)

src/questions/databaseHost.ts (3)

src/utils/abort.ts (1)

• abort (5-8)

src/questions/databaseEngine.ts (1)

• databaseDialectResponse (5-26)

src/questions/orm.ts (1)

• databaseEngine (7-28)

src/generators/db/generateDatabaseTypes.ts (1)

src/types.ts (3)

• DatabaseHost (49-49)
• AuthProvider (40-40)
• DatabaseEngine (45-47)

🔇 Additional comments (13)

src/generators/db/scaffoldDatabase.ts (1)

101-105: LGTM!

The addition of databaseEngine to the generateDatabaseTypes call correctly aligns with the updated function signature and enables proper type generation for PlanetScale variants that need to differentiate between MySQL and PostgreSQL.

src/questions/databaseHost.ts (1)

21-32: LGTM!

The MySQL branch correctly mirrors the existing PostgreSQL and SQLite patterns, with proper cancel handling via isCancel and abort(). The PlanetScale option is appropriately offered for MySQL hosts.

src/generators/db/generateDatabaseTypes.ts (2)

1-6: LGTM!

The addition of DatabaseEngine to the type imports and props correctly enables engine-specific type generation for PlanetScale variants.

---

19-28: LGTM - PlanetScale type generation for MySQL and PostgreSQL.

The conditional branches correctly differentiate between:

• PlanetScale + MySQL → PlanetScaleDatabase from drizzle-orm/planetscale-serverless
• PlanetScale + PostgreSQL → NodePgDatabase from drizzle-orm/node-postgres

This aligns with the import changes in generateImportsBlock.ts where PostgreSQL + PlanetScale uses the standard pg Pool rather than a serverless adapter.

src/generators/project/generateImportsBlock.ts (4)

130-140: LGTM - PostgreSQL import handling for PlanetScale.

The extended logic correctly routes PlanetScale-hosted PostgreSQL to use drizzle-orm/node-postgres with the pg Pool, distinguishing it from local Bun-based PostgreSQL and Neon serverless.

---

175-189: LGTM - Extended noOrmImports for PostgreSQL hosts.

The three-branch logic correctly handles:

• Neon → uses @neondatabase/serverless Pool
• PlanetScale → uses pg Pool
• Default/local → uses Bun's SQL

---

203-212: LGTM - Exclusion of serverless imports for PostgreSQL+PlanetScale.

The condition correctly prevents pushing drizzle-orm/planetscale-serverless imports when using PostgreSQL with PlanetScale, since that combination uses the standard pg driver via drizzle-orm/node-postgres instead.

---

85-85: The Client import from @planetscale/database is correct.

Current PlanetScale SDK documentation confirms Client is the correct export, initialized with new Client({ url: ... }). Usage in generateDBBlock.ts (line 24, line 46) aligns with this pattern. No changes needed.

src/generators/configurations/generatePackageJson.ts (2)

238-241: LGTM - PostgreSQL client dependencies for PlanetScale.

This correctly adds the pg client (8.11.0) and its types (8.6.1) when using PlanetScale with PostgreSQL, aligning with the Pool import from 'pg' in generateImportsBlock.ts (line 183).

---

178-183: The @planetscale/database version 1.19.0 is a valid published package with no known security advisories or breaking changes. The version bump from 1.0.0 is safe to proceed.

src/generators/db/handlerTemplates.ts (3)

106-129: Generalized Postgres Pool query ops correctly cover both Neon and pg-backed drivers

Renaming and reusing the Neon‑specific operations as postgresPgQueryOperations wired into:

• 'postgresql:sql:neon' (Pool from @neondatabase/serverless), and
• 'postgresql:sql:planetscale' (Pool from pg),

makes sense and the query shapes look correct:

• Parameterization via $1, $2 is standard for Pool#query.
• insertUser now writes to (auth_sub, metadata) and throws if no row is returned, matching the rest of the templates.
• Selects for history and user both return rows[0] ?? null, which is consistent with the other SQL drivers.

This is a solid unification of the Pool‑based Postgres paths; just make sure your dependency versions for @neondatabase/serverless and pg match the Pool API used here in the generated projects.

Also applies to: 456-460, 461-465

---

218-276: MySQL local drizzle/SQL templates now correctly key off auth_sub

These MySQL templates look good:

• mysqlSqlQueryOperations.selectUser now filters by WHERE auth_sub = ${authSub}, aligning with how authSub is constructed in the auth handler and with the column name used in every other driver.
• mysqlDrizzleQueryOperations.insertUser now inserts { auth_sub: authSub, metadata: userIdentity } and uses .where(eq(schema.users.auth_sub, authSub)) when re‑selecting, which matches the schema and drizzleQueryOperations.selectUser.

This brings the MySQL paths in line with the rest of the stack’s auth model and fixes the earlier mismatch between insert/select predicates.

Also applies to: 278-308

---

401-416: New driver configurations for PlanetScale paths are coherent with the query templates

The added/updated driverConfigurations entries look internally consistent:

• 'mysql:drizzle:planetscale' uses PlanetScaleDatabase<SchemaType> from drizzle-orm/planetscale-serverless and reuses mysqlDrizzleQueryOperations, which already rely on MySQL dialect features like $returningId() and fit the PlanetScale driver.
• 'mysql:sql:planetscale' uses dbType: 'Client' with import { Client } from '@planetscale/database' and plugs into mysqlPlanetScaleQueryOperations, which are written against Client#execute.
• 'postgresql:drizzle:planetscale' uses NodePgDatabase<SchemaType> from drizzle-orm/node-postgres and the generic drizzleQueryOperations, matching the Pool-based Postgres drizzle adapter.
• 'postgresql:sql:neon' and 'postgresql:sql:planetscale' both use dbType: 'Pool' and the shared postgresPgQueryOperations, which are db.query(...)-based.

This wiring should give you consistent handler templates across all new PlanetScale and pg-backed variants. It’d be worth generating a project for each new key (e.g. mysql:sql:planetscale, mysql:drizzle:planetscale, postgresql:sql:planetscale, postgresql:drizzle:planetscale) and running type‑checks to confirm the imported types (Client, PlanetScaleDatabase, NodePgDatabase, Pool) line up with the actual library APIs in your target versions.

Also applies to: 422-426, 435-450, 456-465

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

src/generators/project/generateImportsBlock.ts (1)

209-213: Use strict equality (===) for comparison.

Line 210 uses loose equality (==) instead of strict equality (===). For consistency with TypeScript best practices, use ===.

 	if (
-		orm == 'drizzle' &&
+		orm === 'drizzle' &&
 		isRemoteHost &&
 		!(databaseEngine === 'postgresql' && databaseHost === 'planetscale')
 	) {

src/generators/project/generateDBBlock.ts (1)

83-96: Consider renaming pool to connection for semantic clarity.

When the host is PlanetScale (MySQL), expr evaluates to new Client(...), so the generated variable pool actually holds a Client instance—not a pool. While this works functionally, the naming is misleading.

-const pool = ${expr}
-const db = drizzle(pool, { schema })
+const connection = ${expr}
+const db = drizzle(connection, { schema })

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 10f7ed9 and 84f8db3.

📒 Files selected for processing (6)

• src/generators/configurations/generatePackageJson.ts (2 hunks)
• src/generators/db/generateDatabaseTypes.ts (1 hunks)
• src/generators/db/handlerTemplates.ts (8 hunks)
• src/generators/project/generateDBBlock.ts (3 hunks)
• src/generators/project/generateImportsBlock.ts (4 hunks)
• src/questions/databaseHost.ts (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• src/generators/db/generateDatabaseTypes.ts
• src/generators/configurations/generatePackageJson.ts

🧰 Additional context used

🧬 Code graph analysis (2)

src/generators/project/generateImportsBlock.ts (1)

src/generators/db/generateDrizzleSchema.ts (1)

• GenerateSchemaProps (61-141)

src/questions/databaseHost.ts (1)

src/utils/abort.ts (1)

• abort (5-8)

🔇 Additional comments (12)

src/questions/databaseHost.ts (1)

21-32: LGTM!

The MySQL branch correctly mirrors the existing PostgreSQL and SQLite branch patterns—handling cancel via abort() and returning undefined for "none" or the selected host otherwise.

src/generators/project/generateImportsBlock.ts (3)

85-85: LGTM!

The import correctly uses Client instead of connect, aligning with the new Client() instantiation pattern used elsewhere in this PR.

---

135-140: LGTM!

Correctly uses drizzle-orm/node-postgres and pg Pool for PostgreSQL + PlanetScale, since PlanetScale's PostgreSQL offering is compatible with the standard pg driver.

---

178-192: LGTM!

The three-way branching for PostgreSQL (neon → Pool from serverless, planetscale → Pool from pg, default → bun SQL) correctly handles all host combinations with appropriate imports.

src/generators/project/generateDBBlock.ts (2)

22-34: LGTM!

The connectionMap correctly distinguishes:

• MySQL + PlanetScale → new Client() (PlanetScale's native MySQL client)
• PostgreSQL + PlanetScale → new Pool() (standard pg driver)

This aligns with the import changes in generateImportsBlock.ts.

---

44-48: LGTM!

The remoteDrizzleInit correctly uses new Client() for PlanetScale, consistent with the updated imports and connectionMap.

src/generators/db/handlerTemplates.ts (6)

106-129: LGTM!

Good rename from postgresNeonQueryOperations to postgresPgQueryOperations—the operations are generic to any pg.Pool client, not Neon-specific.

---

238-253: LGTM!

Correctly retrieves the newly inserted user by auth_sub rather than by auto-increment ID, which is consistent with the insert values and avoids a race condition in high-concurrency scenarios.

---

294-308: LGTM!

The insert statement now correctly terminates with a semicolon, and the subsequent select uses auth_sub for lookup—consistent with the insert values.

---

409-426: LGTM!

The new PlanetScale configurations are correctly structured:

• mysql:drizzle:planetscale uses PlanetScaleDatabase from drizzle-orm/planetscale-serverless
• mysql:sql:planetscale uses Client from @planetscale/database with the new mysqlPlanetScaleQueryOperations

---

443-465: LGTM!

The PostgreSQL + PlanetScale configurations correctly use the standard pg driver:

• postgresql:drizzle:planetscale uses NodePgDatabase from drizzle-orm/node-postgres
• postgresql:sql:planetscale uses Pool from pg with postgresPgQueryOperations

This is appropriate since PlanetScale's PostgreSQL offering is compatible with the standard PostgreSQL protocol.

---

310-365: Well-structured PlanetScale query operations with proper parameterization and error handling.

The implementation correctly uses db.execute() with ? placeholders for parameterized queries, handles insertId for auto-increment columns, and properly returns null for missing results. The execute() method returns a result object containing both insertId (as a string) for INSERT operations and rows for query results, matching the usage in this code.

[absolutejs]

dont completely remove neon the pg is solely for planetscale postgresql

[absolutejs]

neon with postgress doesnt use pg

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/generators/project/generateImportsBlock.ts (1)

209-213: Use strict equality for consistency.

Line 210 uses == instead of === for the orm comparison. While functionally equivalent here (comparing strings), the rest of the codebase uses strict equality.

 if (
-	orm == 'drizzle' &&
+	orm === 'drizzle' &&
 	isRemoteHost &&
 	!(databaseEngine === 'postgresql' && databaseHost === 'planetscale')
 ) {

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 84f8db3 and ae4bc9c.

📒 Files selected for processing (6)

• src/generators/configurations/generatePackageJson.ts (2 hunks)
• src/generators/db/generateDatabaseTypes.ts (1 hunks)
• src/generators/db/handlerTemplates.ts (8 hunks)
• src/generators/project/generateDBBlock.ts (3 hunks)
• src/generators/project/generateImportsBlock.ts (4 hunks)
• src/questions/databaseHost.ts (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• src/generators/db/generateDatabaseTypes.ts

🧰 Additional context used

🧬 Code graph analysis (1)

src/generators/project/generateImportsBlock.ts (1)

src/generators/db/generateDrizzleSchema.ts (1)

• GenerateSchemaProps (61-141)

🔇 Additional comments (14)

src/generators/configurations/generatePackageJson.ts (2)

182-186: LGTM!

The PlanetScale package version has been correctly updated to 1.19.0 as addressed from prior feedback.

---

245-248: LGTM!

The conditional dependency injection for pg and @types/pg is correctly scoped to the PostgreSQL + PlanetScale combination, which aligns with PlanetScale's PostgreSQL compatibility requiring the node-postgres driver.

src/generators/project/generateImportsBlock.ts (3)

83-87: LGTM!

The connector import for PlanetScale correctly uses Client instead of connect, which aligns with the new Client({...}) instantiation pattern used in generateDBBlock.ts.

---

135-140: LGTM!

The PostgreSQL + PlanetScale drizzle path correctly imports drizzle-orm/node-postgres and the pg Pool, which matches the dependency additions in generatePackageJson.ts.

---

178-192: LGTM!

The noOrmImports for PostgreSQL correctly differentiates between Neon (uses @neondatabase/serverless), PlanetScale (uses pg Pool), and local/default (uses Bun SQL).

src/questions/databaseHost.ts (1)

21-32: LGTM!

The MySQL branch correctly follows the established pattern from the PostgreSQL and SQLite branches, with proper cancel handling and consistent return semantics.

src/generators/project/generateDBBlock.ts (3)

22-25: LGTM!

The MySQL + PlanetScale connection correctly uses the Client constructor from @planetscale/database.

---

30-33: LGTM!

The PostgreSQL + PlanetScale connection correctly uses the pg Pool, which aligns with the dependency additions and import configuration.

---

83-90: LGTM!

The mode logic correctly applies only to MySQL/MariaDB when not using PlanetScale, since PlanetScale handles the mode internally.

src/generators/db/handlerTemplates.ts (5)

106-129: LGTM!

Renaming to postgresQueryOperations appropriately reflects that these operations are now shared between Neon and PlanetScale PostgreSQL configurations.

---

294-304: LGTM!

The syntax error has been fixed (semicolon added on line 296), and the selection now correctly uses auth_sub instead of relying on lastInsertRowid, which addresses the prior review feedback.

---

310-365: LGTM!

The mysqlPlanetScaleQueryOperations correctly uses:

• db.execute() with ? placeholders (PlanetScale API)
• result.insertId for retrieving the auto-increment ID
• Proper null checks and error handling
• JSON.stringify(userIdentity) for metadata storage

---

409-426: LGTM!

The MySQL PlanetScale driver configurations correctly reference:

• PlanetScaleDatabase<SchemaType> for Drizzle
• Client type for raw SQL
• Appropriate query operations for each mode

---

443-464: LGTM!

The PostgreSQL PlanetScale configurations correctly use:

• NodePgDatabase<SchemaType> and drizzle-orm/node-postgres for Drizzle
• Pool from pg for raw SQL
• Shared postgresQueryOperations and drizzleQueryOperations

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check remoteDrizzleInit usage and surrounding context
rg -n "remoteDrizzleInit" src/generators/project/generateDBBlock.ts -A2 -B2

Repository: absolutejs/create-absolutejs

Length of output: 439

---

🏁 Script executed:

#!/bin/bash
# Get file info and read the relevant section around line 44-80
wc -l src/generators/project/generateDBBlock.ts

Repository: absolutejs/create-absolutejs

Length of output: 116

---

🏁 Script executed:

#!/bin/bash
# Read the section containing remoteDrizzleInit and the fallback logic
sed -n '40,85p' src/generators/project/generateDBBlock.ts

Repository: absolutejs/create-absolutejs

Length of output: 1309

---

🏁 Script executed:

#!/bin/bash
# Also check connectionMap structure to understand the explicit entries mentioned
sed -n '1,100p' src/generators/project/generateDBBlock.ts | head -n 100

Repository: absolutejs/create-absolutejs

Length of output: 2600

---

🏁 Script executed:

#!/bin/bash
# Find where availableDrizzleDialects is defined
fd -t f "data" src/ | head -20

Repository: absolutejs/create-absolutejs

Length of output: 226

---

🏁 Script executed:

#!/bin/bash
# Search for availableDrizzleDialects definition
rg -n "availableDrizzleDialects" --type ts

Repository: absolutejs/create-absolutejs

Length of output: 844

---

🏁 Script executed:

#!/bin/bash
# Read the data.ts file to see availableDrizzleDialects definition
sed -n '14,30p' src/data.ts

Repository: absolutejs/create-absolutejs

Length of output: 323

---

🏁 Script executed:

#!/bin/bash
# Check databaseHost.ts to see what hosts are available
cat src/questions/databaseHost.ts

Repository: absolutejs/create-absolutejs

Length of output: 1386

---

Remove the remoteDrizzleInit object or document it as future extensibility.

The remoteDrizzleInit entries (neon, planetscale, turso) are unreachable dead code. Every valid database engine + host combination selectable through the CLI has an explicit entry in connectionMap (postgresql/mysql/sqlite with their respective hosts), and other Drizzle-supported engines (gel, singlestore, mariadb) only support 'none' host, which also exist in connectionMap. The fallback at line 80 will never be triggered. Either remove this object or add a comment explaining it's reserved for future extensibility.

🤖 Prompt for AI Agents

In src/generators/project/generateDBBlock.ts around lines 44 to 48, the
remoteDrizzleInit object contains unreachable dead entries (neon, planetscale,
turso) because all valid engine+host combos are handled by connectionMap and the
fallback is never hit; either remove the remoteDrizzleInit constant entirely or
keep it but add a clear comment that it is reserved for future extensibility and
currently unused — update the file by deleting the object if not needed, or add
a one-line explanatory comment above it and mark with TODO/EXPERIMENTAL to avoid
linter warnings about dead code.