feat(cca): PGLite

[Tobbe]

Adds hidden (which means it's experimental) flag --db pglite to create-cedar-app

[netlify]

✅ Deploy Preview for cedarjs ready!

Name	Link
🔨 Latest commit	1fdf664
🔍 Latest deploy log	https://app.netlify.com/projects/cedarjs/deploys/69ca364c0ba0fd0008ba263b
😎 Deploy Preview	https://deploy-preview-1486--cedarjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[nx-cloud]

🤖 Nx Cloud AI Fix

Ensure the fix-ci command is configured to always run in your CI pipeline to get automatic fixes in future runs. For more information, please see https://nx.dev/ci/features/self-healing-ci

---

View your CI Pipeline Execution ↗ for commit 1fdf664

Command	Status	Duration	Result
nx run-many -t build:pack --exclude create-ceda...	✅ Succeeded	2s	View ↗
nx run-many -t build	✅ Succeeded	6s	View ↗
nx run-many -t test --minWorkers=1 --maxWorkers=4	✅ Succeeded	5s	View ↗
nx run-many -t test:types	✅ Succeeded	12s	View ↗

---

☁️ Nx Cloud last updated this comment at 2026-03-30 08:53:44 UTC

[greptile-apps]

Greptile Summary

This PR adds an experimental (hidden) --db pglite flag to create-cedar-app, allowing users to scaffold a Cedar app backed by PGlite — an in-process PostgreSQL compiled to WASM — instead of the default SQLite.

The implementation is clean and well-thought-out:

• Overlay approach: PGlite-specific files (db.ts, schema.prisma, api/package.json, .env.defaults, prisma.config.mts) live in a database-overlays/pglite/ directory and are copied on top of the base ESM template, keeping changes isolated.
• ESM-only constraint is enforced at the CLI level (--db pglite without --esm exits with a clear error), which is correct since top-level await in db.ts requires ESM format.
• prisma.config.mts uses top-level await to ensure PGlite is fully started before Prisma CLI runs, fixing the previously noted fire-and-forget race condition from the CJS config iteration.
• Port conflict detection in prisma.config.mts correctly skips starting a second PGlite instance when Cedar's dev server (yarn cedar dev) already has one running via db.ts.
• The runtime version row added to docs/implementation-docs/2026-03-26-cedarjs-project-overview.md (Node 24, Vite 7, Fastify 5, Apollo Client 3, Prisma 7, React 18/19) is consistent with the codebase.

One minor robustness gap was found: parseInt(url.port, 10) in both db.ts and prisma.config.mts returns NaN when DATABASE_URL omits an explicit port, which would be passed to PGLiteSocketServer. The default .env.defaults always specifies :5433 so this is a non-issue in practice, but a || 5432 fallback would be safer.

Confidence Score: 5/5

Safe to merge — this is a hidden/experimental flag and the only findings are P2 style suggestions

All remaining findings are P2 (minor robustness improvements). The implementation is correct for the documented happy path, and the experimental nature of the flag (hidden, ESM-only) appropriately scopes the surface area. No blocking issues found.

packages/create-cedar-app/database-overlays/pglite/api/src/lib/db.ts and packages/create-cedar-app/database-overlays/pglite/api/prisma.config.mts — both have the same minor parseInt(url.port) gap

Important Files Changed

Filename	Overview
packages/create-cedar-app/database-overlays/pglite/api/src/lib/db.ts	New PGlite db.ts: starts PGlite socket server using host/port from DATABASE_URL, then connects PrismaPg to the same URL — correct and well-structured, but parseInt(url.port, 10) has no fallback for a URL without an explicit port
packages/create-cedar-app/database-overlays/pglite/api/prisma.config.mts	New Prisma CLI config for PGlite: uses top-level await (fixing the prior CJS race condition), checks if port is in use before starting PGlite, but parseInt(url.port, 10) also has no fallback for empty port strings
packages/create-cedar-app/src/create-cedar-app.ts	Adds hidden --database/--db flag, validates pglite requires --esm, deletes template's prisma.config.cjs before applying overlay, and records telemetry — all looks correct
packages/create-cedar-app/database-overlays/pglite/.env.defaults	Sets DATABASE_URL to localhost:5433 (PGlite socket port), consistent with how db.ts and prisma.config.mts derive the port dynamically from this URL
packages/create-cedar-app/database-overlays/pglite/api/db/schema.prisma	PostgreSQL datasource with no hardcoded url — correct for PGlite adapter-based connection
packages/create-cedar-app/database-overlays/pglite/api/package.json	Replaces better-sqlite3 with pglite, pglite-socket, and pg dependencies — correct replacements, retains "type": "module" for ESM
docs/implementation-docs/2026-03-26-cedarjs-project-overview.md	Adds runtime version row (Node 24, Vite 7, Fastify 5, Apollo Client 3, Prisma 7, React 18/19) — versions are consistent with the codebase and accurate
docs/implementation-plans/pglite-database-support-plan.md	New implementation plan document for PGlite support — comprehensive, with known limitations called out in Future Considerations

_{Reviews (6): Last reviewed commit: "Merge branch 'main' into tobbe-create-pg..." | Re-trigger Greptile}

[Tobbe]

@greptileai you said

Prisma v7's defineConfig supports a migrate.beforeAll lifecycle hook designed for exactly this use case:

I can't find any docs on this. Are you sure there's a beforeAll hook? If not, how do I fix the race condition?

[greptile-apps]

You're absolutely right - I apologize for the error. There is no migrate.beforeAll hook in Prisma v7's defineConfig. I made that up.

Here are the actual solutions to fix the race condition:

Option 1: Remove PGlite startup from prisma.config.cjs (simplest)

Since db.ts already starts PGlite with top-level await, remove the startup logic from prisma.config.cjs:

const { defineConfig, env } = require('prisma/config')

const config = defineConfig({
  schema: 'db/schema.prisma',
  migrations: {
    path: 'db/migrations',
    seed: 'yarn cedar exec seed',
  },
  datasource: {
    url: env('DATABASE_URL'),
  },
})

module.exports = config

Then document that users should have the dev server running (which starts PGlite via db.ts) before running migrations.

Option 2: Create a setup script

Add a scripts/start-pglite.mjs that uses ESM with top-level await:

import { startPglite } from '../src/lib/pglite-server.js'
await startPglite(process.env.DATABASE_URL)

Then wrap Prisma commands: node scripts/start-pglite.mjs && prisma migrate dev

Option 3: Use deasync (not recommended)

You could use the deasync package to block until PGlite starts, but this is generally a code smell.

I recommend Option 1 - it's the cleanest since PGlite startup is already handled in db.ts for runtime, and migrations should run while the dev server is active anyway.

[github-actions]

The changes in this PR are now available on npm.

Try them out by running yarn cedar upgrade -t 4.0.0-canary.13701