feat(build): update prisma extension to work with generated clients and rust-free clients

[ericallam]

The prismaExtension has been completely redesigned to support multiple Prisma versions and deployment strategies. This update introduces three distinct modes to handle the evolving Prisma ecosystem, from legacy setups to the upcoming Prisma 7.

Highlights:

• 🎯 Three modes: Legacy, Engine-Only, and Modern
• 🎉 NEW: Support for prisma.config.ts files (Legacy Mode)
• 🔍 NEW: Enhanced version detection with filesystem fallback

Breaking Changes

The prismaExtension now requires an explicit mode parameter. Existing configurations without a mode will need to be updated.

Note: All other existing options remain backward compatible. The new configFile option is optional and doesn't affect existing setups using the schema option.

Before

import { prismaExtension } from "@trigger.dev/build/extensions/prisma";

extensions: [
  prismaExtension({
    schema: "prisma/schema.prisma",
    migrate: true,
    typedSql: true,
    directUrlEnvVarName: "DATABASE_URL_UNPOOLED",
  }),
];

After

import { prismaExtension } from "@trigger.dev/build/extensions/prisma";

extensions: [
  prismaExtension({
    mode: "legacy", // ← MODE IS NOW REQUIRED
    schema: "prisma/schema.prisma",
    migrate: true,
    typedSql: true,
    directUrlEnvVarName: "DATABASE_URL_UNPOOLED",
  }),
];

New Features

1. Legacy Mode

Use when: You're using Prisma 6.x or earlier with the prisma-client-js provider.

Features:

• Automatic prisma generate during deployment
• Supports single-file schemas (prisma/schema.prisma)
• Supports multi-file schemas (Prisma 6.7+, directory-based schemas)
• NEW: Supports Prisma config files (prisma.config.ts) via @prisma/config package
• Migration support with migrate: true
• TypedSQL support with typedSql: true
• Custom generator selection
• Handles Prisma client versioning automatically (with filesystem fallback detection)
• Automatic extraction of schema and migrations paths from config files

Schema Configuration:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["typedSql"]
}

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_URL_UNPOOLED")
}

Extension Configuration:

// Single-file schema
prismaExtension({
  mode: "legacy",
  schema: "prisma/schema.prisma",
  migrate: true,
  typedSql: true,
  directUrlEnvVarName: "DATABASE_URL_UNPOOLED",
});

// Multi-file schema (Prisma 6.7+)
prismaExtension({
  mode: "legacy",
  schema: "./prisma", // ← Point to directory
  migrate: true,
  typedSql: true,
  directUrlEnvVarName: "DATABASE_URL_UNPOOLED",
});

Tested Versions:

• Prisma 6.14.0 ✅
• Prisma 6.7.0+ (multi-file schema support) ✅
• Prisma 5.x ✅

---

2. Engine-Only Mode

Use when: You have a custom Prisma client output path and want to manage prisma generate yourself.

Features:

• Only installs Prisma engine binaries (no client generation)
• Automatic version detection from @prisma/client
• Manual override of version and binary target
• Minimal overhead - just ensures engines are available
• You control when and how prisma generate runs

Schema Configuration:

generator client {
  provider      = "prisma-client-js"
  output        = "../src/generated/prisma"
  // Ensure the "debian-openssl-3.0.x" binary target is included for deployment to the trigger.dev cloud
  binaryTargets = ["native", "debian-openssl-3.0.x"]
}

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_URL_UNPOOLED")
}

Extension Configuration:

// Auto-detect version
prismaExtension({
  mode: "engine-only",
});

// Explicit version (recommended for reproducible builds)
prismaExtension({
  mode: "engine-only",
  version: "6.19.0",
});

Important Notes:

• You must run prisma generate yourself (typically in a prebuild script)
• Your schema must include the correct binaryTargets for deployment to the trigger.dev cloud. The binary target is debian-openssl-3.0.x.
• The extension sets PRISMA_QUERY_ENGINE_LIBRARY and PRISMA_QUERY_ENGINE_SCHEMA_ENGINE environment variables to the correct paths for the binary targets.

package.json Example:

{
  "scripts": {
    "prebuild": "prisma generate",
    "dev": "trigger dev",
    "deploy": "trigger deploy"
  }
}

Tested Versions:

• Prisma 6.19.0 ✅
• Prisma 6.16.0+ ✅

---

3. Modern Mode

Use when: You're using Prisma 6.16+ with the new prisma-client provider (with engineType = "client") or preparing for Prisma 7.

Features:

• Designed for the new Prisma architecture
• Zero configuration required
• Automatically marks @prisma/client as external
• Works with Prisma 7 beta releases & Prisma 7 when released
• You manage client generation (like engine-only mode)

Schema Configuration (Prisma 6.16+ with engineType):

generator client {
  provider        = "prisma-client"
  output          = "../src/generated/prisma"
  engineType      = "client"
  previewFeatures = ["views"]
}

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_URL_UNPOOLED")
}

Schema Configuration (Prisma 7):

generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

datasource db {
  provider = "postgresql"
}

Extension Configuration:

prismaExtension({
  mode: "modern",
});

Prisma Config (Prisma 7):

// prisma.config.ts
import { defineConfig, env } from "prisma/config";
import "dotenv/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
  },
  datasource: {
    url: env("DATABASE_URL"),
  },
});

Important Notes:

• You must run prisma generate yourself
• Requires Prisma 6.16.0+ or Prisma 7 beta
• The new prisma-client provider generates plain TypeScript (no Rust binaries)
• Requires database adapters (e.g., @prisma/adapter-pg for PostgreSQL)

Tested Versions:

• Prisma 6.16.0 with engineType = "client" ✅
• Prisma 6.20.0-integration-next.8 (Prisma 7 beta) ✅

---

Migration Guide

From Old prismaExtension to Legacy Mode

If you were using the previous prismaExtension, migrate to Legacy Mode:

// Old
prismaExtension({
  schema: "prisma/schema.prisma",
  migrate: true,
});

// New
prismaExtension({
  mode: "legacy", // ← Add this
  schema: "prisma/schema.prisma",
  migrate: true,
});

From Managing Your Own Prisma Setup

If you previously handled Prisma generation yourself and just needed engine binaries, use Engine-Only Mode:

prismaExtension({
  mode: "engine-only",
  version: "6.19.0", // Match your @prisma/client version
});

Preparing for Prisma 7

If you want to adopt the new Prisma architecture, use Modern Mode:

1. Update your schema to use prisma-client provider
2. Add database adapters to your dependencies
3. Configure the extension:

prismaExtension({
  mode: "modern",
});

---

Version Compatibility Matrix

Prisma Version	Recommended Mode	Notes
< 5.0	Legacy	Older Prisma versions
5.0 - 6.15	Legacy	Standard Prisma setup
6.7+	Legacy	Multi-file schema support
6.16+	Engine-Only or Modern	Modern mode requires engineType = "client"
6.20+ (7.0 beta)	Modern	Prisma 7 with new architecture

---

Prisma Config File Support (Prisma 6+)

NEW: Legacy Mode now supports loading configuration from a prisma.config.ts file using the official @prisma/config package.

Use when: You want to use Prisma's new config file format (Prisma 6+) to centralize your Prisma configuration.

Benefits:

• Single source of truth for Prisma configuration
• Automatic extraction of schema location and migrations path
• Type-safe configuration with TypeScript
• Works seamlessly with Prisma 7's config-first approach

prisma.config.ts:

import { defineConfig, env } from "prisma/config";
import "dotenv/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
  },
  datasource: {
    url: env("DATABASE_URL"),
    directUrl: env("DATABASE_URL_UNPOOLED"),
  },
});

trigger.config.ts:

import { prismaExtension } from "@trigger.dev/build/extensions/prisma";

prismaExtension({
  mode: "legacy",
  configFile: "./prisma.config.ts", // ← Use config file instead of schema
  migrate: true,
  directUrlEnvVarName: "DATABASE_URL_UNPOOLED", // For migrations
});

What gets extracted:

• schema - The schema file or directory path
• migrations.path - The migrations directory path (if specified)

Note: Either schema or configFile must be specified, but not both.

When to use which:

Use schema option	Use configFile option
Standard Prisma setup	Using Prisma 6+ with config files
Single or multi-file schemas	Preparing for Prisma 7
No prisma.config.ts file	Centralized configuration needed
Simple setup	Want migrations path in config

---

Multi-File Schema Support (Prisma 6.7+)

Prisma 6.7 introduced support for splitting your schema across multiple files in a directory structure.

Example Structure:

prisma/
├── schema.prisma (main file with generator/datasource)
├── models/
│   ├── users.prisma
│   └── posts.prisma
└── sql/
    └── getUserByEmail.sql

Configuration:

prismaExtension({
  mode: "legacy",
  schema: "./prisma", // ← Point to directory instead of file
  migrate: true,
  typedSql: true,
});

package.json:

{
  "prisma": {
    "schema": "./prisma"
  }
}

---

TypedSQL Support

TypedSQL is available in Legacy Mode for Prisma 5.19.0+ with the typedSql preview feature.

Schema Configuration:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["typedSql"]
}

Extension Configuration:

prismaExtension({
  mode: "legacy",
  schema: "prisma/schema.prisma",
  typedSql: true, // ← Enable TypedSQL
});

Usage in Tasks:

import { db, sql } from "./db";

const users = await db.$queryRawTyped(sql.getUserByEmail("[email protected]"));

---

Database Migration Support

Migrations are supported in Legacy Mode only.

Extension Configuration:

// Using schema option
prismaExtension({
  mode: "legacy",
  schema: "prisma/schema.prisma",
  migrate: true, // ← Run migrations on deployment
  directUrlEnvVarName: "DATABASE_URL_UNPOOLED", // For connection pooling
});

// Using configFile option
prismaExtension({
  mode: "legacy",
  configFile: "./prisma.config.ts", // ← Migrations path extracted from config
  migrate: true,
});

What This Does:

1. Copies prisma/migrations/ to the build output
2. Runs prisma migrate deploy before generating the client
3. Uses the directUrlEnvVarName for unpooled connections (required for migrations)

NEW: When using configFile, the migrations path is automatically extracted from your prisma.config.ts:

// prisma.config.ts
export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations", // ← Automatically used by the extension
  },
});

---

Binary Targets and Deployment

Trigger.dev Cloud

The default binary target is debian-openssl-3.0.x for Trigger.dev Cloud deployments.

Legacy Mode: Handled automatically ✅

Engine-Only Mode: Specify in schema like so:

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-3.0.x"]
}

Modern Mode: Handled by database adapters ✅

Self-Hosted / Local Deployment

For local deployments (e.g., Docker on macOS), you may need a different binary target like so:

prismaExtension({
  mode: "engine-only",
  version: "6.19.0",
  binaryTarget: "linux-arm64-openssl-3.0.x", // For macOS ARM64
});

---

Environment Variables

Required Variables

All modes:

• DATABASE_URL: Your database connection string

Legacy mode with migrations:

• DATABASE_URL_UNPOOLED (or your custom directUrlEnvVarName): Direct database connection for migrations

Auto-Set Variables

Engine-Only mode sets:

• PRISMA_QUERY_ENGINE_LIBRARY: Path to the query engine
• PRISMA_QUERY_ENGINE_SCHEMA_ENGINE: Path to the schema engine

---

Troubleshooting

"Could not find Prisma schema"

Legacy Mode: Ensure the schema path is correct relative to your working directory.

// If your project structure is:
// project/
//   trigger.config.ts
//   prisma/
//     schema.prisma

prismaExtension({
  mode: "legacy",
  schema: "./prisma/schema.prisma", // Correct
  // schema: "prisma/schema.prisma", // Also works
});

"Could not determine @prisma/client version"

NEW: The extension now includes improved version detection that tries multiple strategies:

1. Check if @prisma/client is imported in your code (externals)
2. Use the version option if specified
3. NEW: Detect from filesystem by looking for @prisma/client or prisma in node_modules

Legacy Mode: The extension will automatically detect the version from your installed packages. If it still fails, specify the version explicitly:

prismaExtension({
  mode: "legacy",
  schema: "prisma/schema.prisma",
  version: "6.19.0", // ← Add explicit version
});

Engine-Only Mode: Specify the version explicitly:

prismaExtension({
  mode: "engine-only",
  version: "6.19.0", // ← Add explicit version
});

"Binary target not found"

Engine-Only Mode: Make sure your schema includes the deployment binary target:

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "linux-arm64-openssl-3.0.x"]
}

"Module not found: @prisma/client/sql"

Legacy Mode: Make sure typedSql: true is set and you have Prisma 5.19.0+:

prismaExtension({
  mode: "legacy",
  schema: "prisma/schema.prisma",
  typedSql: true, // ← Required for TypedSQL
});

"Config file not found" or Config Loading Errors

Legacy Mode with configFile: Ensure the config file path is correct:

prismaExtension({
  mode: "legacy",
  configFile: "./prisma.config.ts", // Path relative to project root
  migrate: true,
});

Requirements:

• The config file must exist at the specified path
• Your project must have the prisma package installed (Prisma 6+)
• The config file must have a default export
• The config must specify a schema path

Debugging: Use --log-level debug in your trigger deploy command to see detailed logs:

npx trigger.dev@latest deploy --log-level debug

Then grep for [PrismaExtension] in your build logs to see detailed information about config loading, schema resolution, and migrations setup.

---

Complete Examples

Example 1: Standard Prisma 6 Setup (Legacy Mode)

prisma/schema.prisma:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["typedSql"]
}

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_URL_UNPOOLED")
}

trigger.config.ts:

import { defineConfig } from "@trigger.dev/sdk";
import { prismaExtension } from "@trigger.dev/build/extensions/prisma";

export default defineConfig({
  project: process.env.TRIGGER_PROJECT_REF!,
  build: {
    extensions: [
      prismaExtension({
        mode: "legacy",
        schema: "prisma/schema.prisma",
        migrate: true,
        typedSql: true,
        directUrlEnvVarName: "DATABASE_URL_UNPOOLED",
      }),
    ],
  },
});

---

Example 2: Multi-File Schema (Legacy Mode)

prisma/schema.prisma:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["typedSql"]
}

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_URL_UNPOOLED")
}

prisma/models/users.prisma:

model User {
  id        String  @id @default(cuid())
  email     String  @unique
  name      String?
  posts     Post[]
}

prisma/models/posts.prisma:

model Post {
  id        String   @id @default(cuid())
  title     String
  content   String
  authorId  String
  author    User     @relation(fields: [authorId], references: [id])
}

package.json:

{
  "prisma": {
    "schema": "./prisma"
  }
}

trigger.config.ts:

prismaExtension({
  mode: "legacy",
  schema: "./prisma", // ← Directory, not file
  migrate: true,
  typedSql: true,
  directUrlEnvVarName: "DATABASE_URL_UNPOOLED",
});

---

Example 3: Using Prisma Config File (Legacy Mode)

NEW: Use a prisma.config.ts file to centralize your Prisma configuration.

prisma.config.ts:

import { defineConfig, env } from "prisma/config";
import "dotenv/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
  },
  datasource: {
    url: env("DATABASE_URL"),
    directUrl: env("DATABASE_URL_UNPOOLED"),
  },
});

prisma/schema.prisma:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["typedSql"]
}

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_URL_UNPOOLED")
}

model User {
  id        String  @id @default(cuid())
  email     String  @unique
  name      String?
}

trigger.config.ts:

import { defineConfig } from "@trigger.dev/sdk";
import { prismaExtension } from "@trigger.dev/build/extensions/prisma";

export default defineConfig({
  project: process.env.TRIGGER_PROJECT_REF!,
  build: {
    extensions: [
      prismaExtension({
        mode: "legacy",
        configFile: "./prisma.config.ts", // ← Load from config file
        migrate: true,
        typedSql: true,
        // schema and migrations path are extracted from prisma.config.ts
      }),
    ],
  },
});

src/db.ts:

import { PrismaClient } from "@prisma/client";
export * as sql from "@prisma/client/sql";

export const db = new PrismaClient({
  datasources: {
    db: {
      url: process.env.DATABASE_URL,
    },
  },
});

---

Example 4: Custom Output Path (Engine-Only Mode)

prisma/schema.prisma:

generator client {
  provider      = "prisma-client-js"
  output        = "../src/generated/prisma"
  binaryTargets = ["native", "linux-arm64-openssl-3.0.x"]
}

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DATABASE_URL_UNPOOLED")
}

package.json:

{
  "scripts": {
    "generate": "prisma generate",
    "dev": "pnpm generate && trigger dev",
    "deploy": "trigger deploy"
  }
}

trigger.config.ts:

prismaExtension({
  mode: "engine-only",
  version: "6.19.0",
  binaryTarget: "linux-arm64-openssl-3.0.x",
});

src/db.ts:

import { PrismaClient } from "./generated/prisma/client.js";

export const db = new PrismaClient({
  datasources: {
    db: {
      url: process.env.DATABASE_URL,
    },
  },
});

---

Example 5: Prisma 7 Beta (Modern Mode)

prisma/schema.prisma:

generator client {
  provider = "prisma-client"
  output   = "../src/generated/prisma"
}

datasource db {
  provider = "postgresql"
}

prisma.config.ts:

import { defineConfig, env } from "prisma/config";
import "dotenv/config";

export default defineConfig({
  schema: "prisma/schema.prisma",
  migrations: {
    path: "prisma/migrations",
  },
  datasource: {
    url: env("DATABASE_URL"),
  },
});

package.json:

{
  "dependencies": {
    "@prisma/client": "6.20.0-integration-next.8",
    "@prisma/adapter-pg": "6.20.0-integration-next.8"
  },
  "scripts": {
    "generate": "prisma generate",
    "dev": "pnpm generate && trigger dev",
    "deploy": "trigger deploy"
  }
}

trigger.config.ts:

prismaExtension({
  mode: "modern",
});

src/db.ts:

import { PrismaClient } from "./generated/prisma/client.js";
import { PrismaPg } from "@prisma/adapter-pg";

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL!,
});

export const db = new PrismaClient({ adapter });

---

[changeset-bot]

🦋 Changeset detected

Latest commit: eaeb102

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 24 packages

Name	Type
@trigger.dev/build	Patch
trigger.dev	Patch
@trigger.dev/python	Patch
d3-chat	Patch
references-d3-openai-agents	Patch
references-nextjs-realtime	Patch
references-realtime-streams	Patch
@trigger.dev/core	Patch
@trigger.dev/react-hooks	Patch
@trigger.dev/redis-worker	Patch
@trigger.dev/rsc	Patch
@trigger.dev/schema-to-json	Patch
@trigger.dev/sdk	Patch
@trigger.dev/database	Patch
@trigger.dev/otlp-importer	Patch
@internal/cache	Patch
@internal/clickhouse	Patch
@internal/redis	Patch
@internal/replication	Patch
@internal/run-engine	Patch
@internal/schedule-engine	Patch
@internal/testcontainers	Patch
@internal/tracing	Patch
@internal/zod-worker	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Walkthrough

This PR redesigns the Prisma extension into three explicit modes (Legacy, Engine‑Only, Modern) and makes the mode parameter required. It adds prisma.config.ts support and enhanced Prisma version detection (externals → option → filesystem), plus multi‑file schema and migrations handling. Engine‑Only mode installs engine binaries and sets runtime env vars. New helper utilities for version/config resolution and filesystem path resolution were added, and mlly is re-exported (ESM + CJS). package.json for packages/build gained dependencies/devDependencies. Externals matching regex was broadened. CI Node.js versions and .nvmrc bumped to v20.19.0.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

• packages/build/src/extensions/prisma.ts — major structural refactor, new exported types/classes, mode dispatch, config loading, version detection, multi-file schema/migrations handling, lifecycle changes.
• packages/build/src/imports/mlly.ts and packages/build/src/imports/mlly-cjs.cts — ESM/CJS re-exports; verify runtime interoperability and typings.
• packages/build/package.json — added runtime/dev deps (@prisma/config, mlly, resolve, esbuild, etc.); check versions and build implications.
• packages/cli-v3/src/build/externals.ts — broadened external regexp; review for unintentional matches.
• CI config and .nvmrc — Node.js bumped to 20.19.0 across workflows; confirm compatibility with toolchain and runners.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Description check	❓ Inconclusive	Description is comprehensive with breaking changes, three modes explained, migration guide, examples, and version matrix, but lacks required template sections (Closes #issue, Checklist, Testing steps, Screenshots).	Add PR template sections: issue reference, checklist completion, explicit testing steps taken, and screenshots if applicable.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title accurately summarizes main change: prisma extension redesign to support generated and rust-free clients across multiple modes.

✨ 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 ea-branch-102

---

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

Caution

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

⚠️ Outside diff range comments (1)

packages/build/src/extensions/prisma.ts (1)

500-602: Respect typedSql.path configuration from prisma.config.ts to prevent build failures with custom SQL paths

This is a functional issue for users adopting prisma.config.ts with custom typedSql.path. The codebase verification confirms:

1. Prisma's config supports custom typedSql.path in prisma.config.ts
2. loadPrismaConfig() receives configResult.config containing the full Prisma config (including typedSql), but only extracts schema and migrationsPath (line 333), ignoring typedSql.path
3. _loadedConfig (line 408) lacks a typedSqlPath property, so the loaded config value is never stored
4. onBuildComplete() hardcodes the SQL path as ${prismaDirForSql}/sql (line 543), causing readdir() to throw ENOENT if the user has configured a different typedSql.path (e.g., db/queries)

Required fixes:

• Update loadPrismaConfig() to extract and return typedSql.path from configResult.config.typedSql?.path
• Add typedSqlPath?: string to the _loadedConfig type (line 408)
• In onBuildComplete(), prefer this._loadedConfig?.typedSqlPath when available; otherwise fall back to the inferred /sql directory
• Wrap the readdir() call in a try-catch to gracefully handle missing directories instead of throwing

🧹 Nitpick comments (2)

packages/build/src/extensions/prisma.ts (2)

11-150: API shape for the three modes looks solid; add a guard for unknown mode

The new PrismaLegacyModeExtensionOptions / PrismaEngineOnlyModeExtensionOptions / PrismaEngineModernModeExtensionOptions types and the prismaExtension(options) dispatcher are a clean way to expose the three modes, and the JSDoc matches what’s described in the changeset.

One small robustness improvement: in prismaExtension, if options.mode is an unexpected string (e.g. from plain JS config), the function currently returns undefined. Adding a default branch that throws a clear error (listing valid modes) would produce a much better failure mode for misconfigurations, especially for non-TypeScript consumers.

 export function prismaExtension(options: PrismaExtensionOptions): BuildExtension {
   switch (options.mode) {
     case "legacy":
       return new PrismaLegacyModeExtension(options);
     case "engine-only":
       return new PrismaEngineOnlyModeExtension(options);
     case "modern":
       return new PrismaEngineModernModeExtension(options);
+    default: {
+      const mode: never = options.mode as never;
+      throw new Error(
+        `Unknown Prisma extension mode "${String(
+          mode
+        )}". Expected one of "legacy" | "engine-only" | "modern".`
+      );
+    }
   }
 }

Also applies to: 358-400, 884-896

---

604-688: Multi-file schema copying works; filter is slightly Unix-centric

The multi-file vs schema-folder vs single-file branching looks correct:

• Directory schemas (./prisma) are copied recursively, skipping migrations and sql (which are handled separately) and omitting --schema on the generate command.
• prisma/schema/*.prisma schemas copy only the .prisma files and also skip --schema.
• Single-file schemas copy schema.prisma to the output and pass --schema=./prisma/schema.prisma.

Two minor details:

1. In the multi-file case, the filter uses relativePath.startsWith("/migrations") and /sql. On Windows, relativePath will likely start with \\migrations, so these directories won’t be filtered and will be copied twice (once here, once in the explicit migrations/sql handling). It’s harmless but noisy. Using path.sep or path.relative with a split on separators would make this platform-independent.
2. When generatorFlags is empty, the generate command strings end with a trailing space, which is harmless but could be trimmed when building commands.

Both are small polish items; behavior is correct as-is.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1a7ee24 and 78c9f87.

⛔ Files ignored due to path filters (68)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
• references/prisma-6-client/.env.example is excluded by !references/**
• references/prisma-6-client/.gitignore is excluded by !references/**
• references/prisma-6-client/package.json is excluded by !references/**
• references/prisma-6-client/prisma/migrations/20251114141701_add_initial_migration/migration.sql is excluded by !references/**
• references/prisma-6-client/prisma/migrations/20251114143739_add_product_model/migration.sql is excluded by !references/**
• references/prisma-6-client/prisma/migrations/migration_lock.toml is excluded by !references/**
• references/prisma-6-client/prisma/schema.prisma is excluded by !references/**
• references/prisma-6-client/src/db.ts is excluded by !references/**
• references/prisma-6-client/src/trigger/tasks.ts is excluded by !references/**
• references/prisma-6-client/trigger.config.ts is excluded by !references/**
• references/prisma-6-client/tsconfig.json is excluded by !references/**
• references/prisma-6-config/.env.example is excluded by !references/**
• references/prisma-6-config/.gitignore is excluded by !references/**
• references/prisma-6-config/package.json is excluded by !references/**
• references/prisma-6-config/prisma.config.ts is excluded by !references/**
• references/prisma-6-config/prisma/migrations/20251117171313_add_initial_migration/migration.sql is excluded by !references/**
• references/prisma-6-config/prisma/migrations/migration_lock.toml is excluded by !references/**
• references/prisma-6-config/prisma/schema.prisma is excluded by !references/**
• references/prisma-6-config/src/db.ts is excluded by !references/**
• references/prisma-6-config/src/trigger/tasks.ts is excluded by !references/**
• references/prisma-6-config/trigger.config.ts is excluded by !references/**
• references/prisma-6-config/tsconfig.json is excluded by !references/**
• references/prisma-6-multi-file/.env.example is excluded by !references/**
• references/prisma-6-multi-file/package.json is excluded by !references/**
• references/prisma-6-multi-file/prisma/migrations/20251113161257_add_initial_migration/migration.sql is excluded by !references/**
• references/prisma-6-multi-file/prisma/migrations/migration_lock.toml is excluded by !references/**
• references/prisma-6-multi-file/prisma/models/posts.prisma is excluded by !references/**
• references/prisma-6-multi-file/prisma/models/users.prisma is excluded by !references/**
• references/prisma-6-multi-file/prisma/schema.prisma is excluded by !references/**
• references/prisma-6-multi-file/prisma/sql/getUserByEmail.sql is excluded by !references/**
• references/prisma-6-multi-file/src/db.ts is excluded by !references/**
• references/prisma-6-multi-file/src/trigger/tasks.ts is excluded by !references/**
• references/prisma-6-multi-file/trigger.config.ts is excluded by !references/**
• references/prisma-6-multi-file/tsconfig.json is excluded by !references/**
• references/prisma-6-output/.env.example is excluded by !references/**
• references/prisma-6-output/.gitignore is excluded by !references/**
• references/prisma-6-output/package.json is excluded by !references/**
• references/prisma-6-output/prisma/migrations/20251113213202_add_initial_migration/migration.sql is excluded by !references/**
• references/prisma-6-output/prisma/migrations/migration_lock.toml is excluded by !references/**
• references/prisma-6-output/prisma/schema.prisma is excluded by !references/**
• references/prisma-6-output/prisma/sql/getUserByEmail.sql is excluded by !references/**
• references/prisma-6-output/src/db.ts is excluded by !references/**
• references/prisma-6-output/src/trigger/tasks.ts is excluded by !references/**
• references/prisma-6-output/trigger.config.ts is excluded by !references/**
• references/prisma-6-output/tsconfig.json is excluded by !references/**
• references/prisma-6/.env.example is excluded by !references/**
• references/prisma-6/package.json is excluded by !references/**
• references/prisma-6/prisma/migrations/20251113155334_add_initial_migration/migration.sql is excluded by !references/**
• references/prisma-6/prisma/migrations/migration_lock.toml is excluded by !references/**
• references/prisma-6/prisma/schema.prisma is excluded by !references/**
• references/prisma-6/prisma/sql/getUserByEmail.sql is excluded by !references/**
• references/prisma-6/src/db.ts is excluded by !references/**
• references/prisma-6/src/trigger/tasks.ts is excluded by !references/**
• references/prisma-6/trigger.config.ts is excluded by !references/**
• references/prisma-6/tsconfig.json is excluded by !references/**
• references/prisma-7/.env.example is excluded by !references/**
• references/prisma-7/.gitignore is excluded by !references/**
• references/prisma-7/.nvmrc is excluded by !references/**
• references/prisma-7/package.json is excluded by !references/**
• references/prisma-7/prisma.config.ts is excluded by !references/**
• references/prisma-7/prisma/migrations/20251113162106_add_initial_migration/migration.sql is excluded by !references/**
• references/prisma-7/prisma/migrations/migration_lock.toml is excluded by !references/**
• references/prisma-7/prisma/schema.prisma is excluded by !references/**
• references/prisma-7/src/db.ts is excluded by !references/**
• references/prisma-7/src/trigger/tasks.ts is excluded by !references/**
• references/prisma-7/trigger.config.ts is excluded by !references/**
• references/prisma-7/tsconfig.json is excluded by !references/**

📒 Files selected for processing (7)

• .changeset/six-vans-rhyme.md (1 hunks)
• .nvmrc (1 hunks)
• packages/build/package.json (1 hunks)
• packages/build/src/extensions/prisma.ts (7 hunks)
• packages/build/src/imports/mlly-cjs.cts (1 hunks)
• packages/build/src/imports/mlly.ts (1 hunks)
• packages/cli-v3/src/build/externals.ts (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (2)

packages/build/src/imports/mlly-cjs.cts (1)

packages/build/src/imports/mlly.ts (1)

• resolvePathSync (5-5)

packages/build/src/extensions/prisma.ts (1)

packages/core/src/v3/build/extensions.ts (2)

• BuildExtension (14-22)
• BuildContext (37-50)

⏰ 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). (3)

• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
• GitHub Check: Analyze (javascript-typescript)

🔇 Additional comments (11)

.nvmrc (1)

1-1: Node version bump looks fine

v20.19.0 is compatible with the existing engines.node >=18.20.0; just make sure CI images and deploy runtime are also on 20.19 so local/CI behavior matches.

.changeset/six-vans-rhyme.md (1)

1-383: Changeset documentation is thorough and consistent with the implementation

The changeset does a good job documenting the new mode-based API, the three modes, and the configFile vs schema behavior, and it matches the exported options and classes in prisma.ts at a high level. This should give users enough context to migrate without surprises.

packages/build/src/extensions/prisma.ts (6)

402-498: Legacy mode onBuildStart: schema/config validation and resolution look correct

The legacy mode’s onBuildStart:

• Enforces exactly one of schema or configFile, which matches the documented behavior.
• When configFile is provided, uses loadPrismaConfig to obtain the schema and optional migrations path and logs them, then resolves the schema path relative to workingDir.
• Verifies the resolved schema path exists and throws a clear error if not.

This matches the changeset description and provides the right guardrails for both direct schema paths and prisma.config.ts setups. (prisma.io)

No changes needed here from a correctness standpoint.

---

692-755: Migrations handling is correct and respects config, with good logging

The migration flow in legacy mode:

• Only runs when options.migrate is truthy.
• Prefers migrations.path from the loaded config (resolved against workingDir), and otherwise defaults to ${prismaDir}/migrations.
• Checks existence before copying, logging a warning and skipping if the directory is missing instead of failing the build.
• Prepends prisma migrate deploy to the command list when migrations are present.

This matches Prisma’s config semantics and the behavior described in the changeset, and the logs will make it clear which path is used. (prisma.io)

No changes needed here.

---

756-805: Env wiring for DATABASE_URL and direct URLs is aligned with expectations

The handling of env.DATABASE_URL, directUrlEnvVarName, and fallbacks for DIRECT_URL / DIRECT_DATABASE_URL matches how Prisma expects these variables to be wired, and the warnings emitted when they’re missing are explicit and actionable.

This is consistent with Prisma’s environment-variable guidance and should be helpful in debugging misconfigured deployments. (prisma.io)

---

877-882: Helper for engine copy commands is correct

generateCpCommandsForLocation correctly uses the current @prisma/engines filename patterns: libquery_engine-<binaryTarget>.so.node for the query engine and schema-engine-<binaryTarget> for the schema engine. These filenames match the current @prisma/engines package layout (e.g., libquery_engine-debian-openssl-3.0.x.so.node, schema-engine-debian-openssl-3.0.x). The helper remains the central place to update if Prisma ever renames these binaries.

---

153-257: Version resolution helper behavior is reasonable

resolvePrismaClientVersion and tryResolvePrismaPackageVersion use mlly's resolvePathSync plus pkg-types to find and read the package.json for @prisma/client or prisma, skipping marker package.json files with only type and minimal fields. This aligns with how Prisma's CLI resolves the applicable npm project by searching the current directory and parent directories.

No blocking issues here; just keep in mind:

• This logic assumes a filesystem layout where @prisma/client / prisma are resolvable from workingDir. If users run builds from a different cwd in a monorepo, that may affect detection until they pass an explicit version in options.
• If you ever need to support custom package names for the Prisma client, tryResolvePrismaPackageVersion can be easily extended to accept overrides.

---

884-896: Modern mode externals behavior is appropriately minimal

Modern mode correctly marks @prisma/client as external for all targets via externalsForTarget, matching the documented "zero configuration" behavior where users manage client generation and adapters themselves. The new prisma-client generator still relies on the @prisma/client runtime, with generated code importing from "@prisma/client/runtime/library", so marking @prisma/client as external is the correct behavior.

packages/cli-v3/src/build/externals.ts (1)

16-20: mlly url option supports both plain strings and file:// URLs—code is correct as-is

The web search confirms mlly's resolvePathSync documentation explicitly accepts url as either a URL or plain string (defaulting to pwd()), and mlly handles path string conversion internally. Your current approach of passing resolveDir as a plain string is fully supported and requires no changes.

The optional suggestion to use pathToFileURL(resolveDir) would be a stylistic choice only—not a requirement—since both forms work correctly per mlly's documented behavior.

packages/build/src/imports/mlly.ts (1)

1-5: Remove unnecessary @ts-ignore directives — mlly has proper TypeScript types

mlly publishes TypeScript types (package.json points "types" to dist/index.d.ts) and the type declarations include resolvePathSync. The current // @ts-ignore comments on both the import and export are unnecessary. The recommended import form is a named import: import { resolvePathSync } from "mlly";, which is what your code already uses.

Simply remove both @ts-ignore directives:

import { resolvePathSync } from "mlly";
export { resolvePathSync };

packages/build/package.json (1)

79-87: Dependencies verified as Node 20.19.0 compatible

The added runtime dependencies (@prisma/config, mlly, resolve) and dev dependencies (@arethetypeswrong/cli, @types/resolve, esbuild) align with the new code paths and have no documented engine constraints blocking Node 20.19.0. Maintain version consistency with other monorepo consumers of esbuild, mlly, and resolve to avoid resolution drift.

[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)

packages/build/src/extensions/prisma.ts (1)

563-601: Ensure prisma/sql exists before copying TypedSQL artifacts

In the typedSql branch, the code computes prismaDirForSql and sqlDestinationPath = join(manifest.outputPath, "prisma", "sql"), then loops through .sql files calling await cp(source, destination) for each.

fs.promises.cp does not create missing parent directories for the destination, so if manifest.outputPath/prisma/sql does not already exist, the copy operation will throw an ENOENT error at build time.

Add the destination directory before the loop:

-import { cp, readdir, readFile } from "node:fs/promises";
+import { cp, mkdir, readdir, readFile } from "node:fs/promises";
@@
-    const sqlDestinationPath = join(manifest.outputPath, "prisma", "sql");
+    const sqlDestinationPath = join(manifest.outputPath, "prisma", "sql");
+    await mkdir(sqlDestinationPath, { recursive: true });
@@
-        const destination = join(sqlDestinationPath, file);
+        const destination = join(sqlDestinationPath, file);

This ensures TypedSQL artifacts can be copied robustly regardless of prior steps.

🧹 Nitpick comments (2)

packages/build/src/extensions/prisma.ts (2)

82-87: Align directUrlEnvVarName “required for migrations” wording with actual behaviour

The JSDoc says directUrlEnvVarName is required for migrations, but onBuildComplete happily runs prisma migrate deploy whenever migrate is true, even if directUrlEnvVarName is undefined (it falls back to DATABASE_URL and optional DIRECT_URL/DIRECT_DATABASE_URL).

To avoid confusing users:

• Either enforce the requirement (e.g., throw or at least warn strongly when migrate: true and directUrlEnvVarName is missing), or
• Relax the wording in the option docs/comments to “recommended when your schema uses a direct URL” and explain the fallback behaviour.

Right now the docs and runtime behaviour diverge slightly.

Also applies to: 692-779

---

391-399: Fail fast on unknown mode values in prismaExtension

The factory currently switches on options.mode and returns an extension for "legacy" | "engine-only" | "modern", but there’s no default case. If somebody passes an invalid mode from JS (or via a future refactor), the function will return undefined and the misconfiguration will only surface later.

It’d be safer to throw immediately with a clear error:

export function prismaExtension(options: PrismaExtensionOptions): BuildExtension {
  switch (options.mode) {
    case "legacy":
      return new PrismaLegacyModeExtension(options);
    case "engine-only":
      return new PrismaEngineOnlyModeExtension(options);
    case "modern":
      return new PrismaEngineModernModeExtension(options);
-  }
+    default: {
+      // Exhaustive check so TS yells if a new mode is added
+      const _exhaustive: never = options.mode as never;
+      throw new Error(`Unsupported prismaExtension mode: ${options.mode}`);
+    }
+  }
}

This keeps runtime behaviour explicit and guards against accidental new/invalid mode strings.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 962035c and 3592646.

⛔ Files ignored due to path filters (33)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
• references/prisma-6-client/.env.example is excluded by !references/**
• references/prisma-6-client/.gitignore is excluded by !references/**
• references/prisma-6-client/package.json is excluded by !references/**
• references/prisma-6-client/prisma/migrations/20251114141701_add_initial_migration/migration.sql is excluded by !references/**
• references/prisma-6-client/prisma/migrations/20251114143739_add_product_model/migration.sql is excluded by !references/**
• references/prisma-6-client/prisma/migrations/migration_lock.toml is excluded by !references/**
• references/prisma-6-client/prisma/schema.prisma is excluded by !references/**
• references/prisma-6-client/src/db.ts is excluded by !references/**
• references/prisma-6-client/src/trigger/tasks.ts is excluded by !references/**
• references/prisma-6-client/trigger.config.ts is excluded by !references/**
• references/prisma-6-client/tsconfig.json is excluded by !references/**
• references/prisma-6-config/.env.example is excluded by !references/**
• references/prisma-6-config/.gitignore is excluded by !references/**
• references/prisma-6-config/package.json is excluded by !references/**
• references/prisma-6-config/prisma.config.ts is excluded by !references/**
• references/prisma-6-config/prisma/migrations/20251117171313_add_initial_migration/migration.sql is excluded by !references/**
• references/prisma-6-config/prisma/migrations/migration_lock.toml is excluded by !references/**
• references/prisma-6-config/prisma/schema.prisma is excluded by !references/**
• references/prisma-6-config/src/db.ts is excluded by !references/**
• references/prisma-6-config/src/trigger/tasks.ts is excluded by !references/**
• references/prisma-6-config/trigger.config.ts is excluded by !references/**
• references/prisma-6-config/tsconfig.json is excluded by !references/**
• references/prisma-6-multi-file/package.json is excluded by !references/**
• references/prisma-6-multi-file/trigger.config.ts is excluded by !references/**
• references/prisma-6-output/package.json is excluded by !references/**
• references/prisma-6-output/prisma/schema.prisma is excluded by !references/**
• references/prisma-6-output/trigger.config.ts is excluded by !references/**
• references/prisma-6/package.json is excluded by !references/**
• references/prisma-6/trigger.config.ts is excluded by !references/**
• references/prisma-7/package.json is excluded by !references/**
• references/prisma-7/prisma/schema.prisma is excluded by !references/**
• references/prisma-7/trigger.config.ts is excluded by !references/**

📒 Files selected for processing (13)

• .changeset/six-vans-rhyme.md (1 hunks)
• .github/workflows/e2e.yml (1 hunks)
• .github/workflows/release.yml (1 hunks)
• .github/workflows/typecheck.yml (1 hunks)
• .github/workflows/unit-tests-internal.yml (2 hunks)
• .github/workflows/unit-tests-packages.yml (2 hunks)
• .github/workflows/unit-tests-webapp.yml (2 hunks)
• .nvmrc (1 hunks)
• packages/build/package.json (1 hunks)
• packages/build/src/extensions/prisma.ts (7 hunks)
• packages/build/src/imports/mlly-cjs.cts (1 hunks)
• packages/build/src/imports/mlly.ts (1 hunks)
• packages/cli-v3/src/build/externals.ts (2 hunks)

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

• .github/workflows/e2e.yml
• packages/build/src/imports/mlly.ts
• packages/build/src/imports/mlly-cjs.cts
• .github/workflows/unit-tests-internal.yml
• .nvmrc
• .github/workflows/unit-tests-webapp.yml
• packages/build/package.json
• .github/workflows/typecheck.yml

🧰 Additional context used

🧬 Code graph analysis (1)

packages/build/src/extensions/prisma.ts (1)

packages/core/src/v3/build/extensions.ts (2)

• BuildExtension (14-22)
• BuildContext (37-50)

⏰ 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). (23)

• GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
• GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
• GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
• GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
• GitHub Check: typecheck / typecheck
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
• GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
• GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
• GitHub Check: Analyze (javascript-typescript)

🔇 Additional comments (6)

.github/workflows/release.yml (1)

47-47: Node.js version aligned consistently.

The bump from 20.11.1 to 20.19.0 is consistent with the coordinated Node.js version alignment across the project's CI/CD workflows.

.github/workflows/unit-tests-packages.yml (2)

61-61: Node.js version bump in unitTests job — consistent with project alignment.

The upgrade to 20.19.0 in the unitTests workflow step aligns with the coordinated Node.js version strategy.

---

119-119: Node.js version bump in merge-reports job — consistent with project alignment.

The upgrade to 20.19.0 in the merge-reports workflow step aligns with the coordinated Node.js version strategy.

packages/cli-v3/src/build/externals.ts (2)

178-180: LGTM! Good observability improvement.

The debug logging addition helps trace which external packages are being registered for resolution, improving debuggability of the externals system.

---

531-531: LGTM! Regex pattern is now more permissive and standard.

The change from [^'"] to . removes an unnecessary restriction on quote characters in subpaths. Since esbuild's args.path contains unquoted import paths and valid import statements don't include quotes, this simplification is appropriate and aligns with the PR's goal to broaden external matching.

.changeset/six-vans-rhyme.md (1)

5-383: Changelog & migration guide look consistent with the implementation

The three-mode description, examples, and version matrix line up with the new Prisma extension code and options; nothing blocking here from a behaviour/accuracy standpoint.