feat(client): remove library engine - #28375
Merged
Merged
Conversation
Contributor
size-limit report 📦
|
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 5, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 5, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 5, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 6, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 6, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 6, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 6, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 6, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 6, 2025
Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
pushed a commit
that referenced
this pull request
Nov 6, 2025
This PR: - gets rid of outdated `Engine` config options. Some of these options should've probably been removed in #28375 - closes [TML-1555](https://linear.app/prisma-company/issue/TML-1555/get-rid-of-outdated-engine-config-options) --------- Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com>
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 7, 2025
Remove the top level QE crates, SQL query connector and QE-specific code from `query-core`, and move the crates used by QC to the `query-compiler` directory. Also removes the Node-API specific code from `driver-adapters` and leaves only the Wasm implementation to be used by `schema-engine-wasm`. Unused MongoDB query connector is left for future reference as we are going to be porting that logic to QC. Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 17, 2025
Remove the top level QE crates, SQL query connector and QE-specific code from `query-core`, and move the crates used by QC to the `query-compiler` directory. Also removes the Node-API specific code from `driver-adapters` and leaves only the Wasm implementation to be used by `schema-engine-wasm`. Unused MongoDB query connector is left for future reference as we are going to be porting that logic to QC. Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 17, 2025
Remove the top level QE crates, SQL query connector and QE-specific code from `query-core`, and move the crates used by QC to the `query-compiler` directory. Also removes the Node-API specific code from `driver-adapters` and leaves only the Wasm implementation to be used by `schema-engine-wasm`. Unused MongoDB query connector is left for future reference as we are going to be porting that logic to QC. Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 17, 2025
Remove the top level QE crates, SQL query connector and QE-specific code from `query-core`, and move the crates used by QC to the `query-compiler` directory. Also removes the Node-API specific code from `driver-adapters` and leaves only the Wasm implementation to be used by `schema-engine-wasm`. Unused MongoDB query connector is left for future reference as we are going to be porting that logic to QC. Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
aqrln
added a commit
that referenced
this pull request
Nov 17, 2025
This PR introduces a new way to configure the Accelerate URL in
preparation to removing `url` from PSL:
```ts
new PrismaClient({
accelerateUrl: "prisma://...",
})
```
This property is mutually exclusive with `adapter`, and exactly one of
them needs to be provided when using `engineType = "client"`.
It also makes a few related changes along the way or as a side effect:
- Contributes towards
[TML-1459](https://linear.app/prisma-company/issue/TML-1459/remove-processenv-loading-from-prisma-cli-and-prismaclient):
the logic related to environment variables was completely removed from
the `RemoteExecutor` code path, along with the `resolveDatasourceUrl`
function.
- Fixes the `@prisma/extension-accelerate` extension which was
inadvertently broken in #28345:
while most of `accelerateUtils` (which were meant to be used by the
removed `AccelerateEngine`) were indeed never used, one specific method
is actually currently used:
`_accelerateEngineConfig.accelerateUtils.resolveDatasourceUrl`. This PR
now restores this function and re-implements it in a different way.
- As a result of this, we now have a new validation and a DX improvement
we didn't use to: now if you apply the Accelerate extension to a client
that's not actually configured to use Accelerate, you will get a very
clear error with a code suggestion.
- Removes `null` support for the `adapter` constructor option, which was
introduced in #21315. It was the
only option that required `null` instead of `undefined` to disable it
explicitly and it was inconsistent with the others. The [motivation for
introducing `null` and making it different from
`undefined`](#21163 (comment))
made total sense for the `LibraryEngine` (where accidentally setting the
`adapter` to `undefined` meant silently using completely different
drivers before that change) but is now obsolete for the `ClientEngine`.
Since we are removing `LibraryEngine` in
#28375, we don't need this
distinction anymore since there are no longer any pitfalls from using
`adapter: undefined`, and removing it here in this PR made the
validation around the combinations of `adapter` and `accelerateUrl`
easier.
- Fixed the incorrect error message when Accelerate URL cannot be
parsed.
Closes:
https://linear.app/prisma-company/issue/TML-1507/env-less-accelerate-url-configuration
aqrln
added a commit
that referenced
this pull request
Nov 17, 2025
This PR: - gets rid of `LibraryEngine` - gets rid of `TARGET_BUILD = 'library'` - gets rid of `binaryTargets` and `engineType` attributes in `prisma-client-js` - gets rid of outdated tests We also had to (temporarily?) disable the following tests: - **integration tests** - **client type tests** - **functional tests** - All tests when using `--generator-type prisma-client-js` - extensions/defineExtensions when using `driverAdapters` and `--remote-executor` - invalid-sqlite-isolation-level - issues/21136-extensions-mocking-library - **e2e tests** - `accelerate-types` - `unsupported-edge-error` - `connection-limit-reached` - `mongodb-notablescan` - `issues/17303-interactive-transaction-errors` - `nextjs-schema-not-found/7_monorepo-noServerComponents-noCustomOutput-noReExport` - `nextjs-schema-not-found/8_monorepo-serverComponents-noCustomOutput-noReExport` - `nextjs-schema-not-found/11_monorepo-noServerComponents-noCustomOutput-noExportIndirect` - `nextjs-schema-not-found/15` - `nextjs-schema-not-found/16` - `nextjs-schema-not-found/17` - `nextjs-schema-not-found/18` We should re-enable them in follow-up PRs. Other TODOs for follow-up PRs: - Change "chunking query" message in `packages/client-engine-runtime/src/interpreter/render-query.ts` - Figure out why functional/omit/test.ts showcases has different snapshots depending on the generator used - Test `wasm-compiler-edge` runtime --- Discoveries: - `wasm-compiler-edge` was never tested before. Adding it to the test matrix, causes failures that are out of scope for this PR. - Testing the `prisma-client-js` generator along with `prisma-client-ts` generator caused some Jest snapshots to fail. For this reason, I raised this issue internally with Alexey and temporarily stopped testing `prisma-client-js`. This should be fixed in a follow-up PR. /integration --------- Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com> Co-authored-by: Oleksii (Alexey) Orlenko <alex@aqrln.net>
aqrln
pushed a commit
that referenced
this pull request
Nov 17, 2025
This PR: - gets rid of outdated `Engine` config options. Some of these options should've probably been removed in #28375 - closes [TML-1555](https://linear.app/prisma-company/issue/TML-1555/get-rid-of-outdated-engine-config-options) --------- Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com>
aqrln
added a commit
that referenced
this pull request
Nov 17, 2025
This PR introduces a new way to configure the Accelerate URL in
preparation to removing `url` from PSL:
```ts
new PrismaClient({
accelerateUrl: "prisma://...",
})
```
This property is mutually exclusive with `adapter`, and exactly one of
them needs to be provided when using `engineType = "client"`.
It also makes a few related changes along the way or as a side effect:
- Contributes towards
[TML-1459](https://linear.app/prisma-company/issue/TML-1459/remove-processenv-loading-from-prisma-cli-and-prismaclient):
the logic related to environment variables was completely removed from
the `RemoteExecutor` code path, along with the `resolveDatasourceUrl`
function.
- Fixes the `@prisma/extension-accelerate` extension which was
inadvertently broken in #28345:
while most of `accelerateUtils` (which were meant to be used by the
removed `AccelerateEngine`) were indeed never used, one specific method
is actually currently used:
`_accelerateEngineConfig.accelerateUtils.resolveDatasourceUrl`. This PR
now restores this function and re-implements it in a different way.
- As a result of this, we now have a new validation and a DX improvement
we didn't use to: now if you apply the Accelerate extension to a client
that's not actually configured to use Accelerate, you will get a very
clear error with a code suggestion.
- Removes `null` support for the `adapter` constructor option, which was
introduced in #21315. It was the
only option that required `null` instead of `undefined` to disable it
explicitly and it was inconsistent with the others. The [motivation for
introducing `null` and making it different from
`undefined`](#21163 (comment))
made total sense for the `LibraryEngine` (where accidentally setting the
`adapter` to `undefined` meant silently using completely different
drivers before that change) but is now obsolete for the `ClientEngine`.
Since we are removing `LibraryEngine` in
#28375, we don't need this
distinction anymore since there are no longer any pitfalls from using
`adapter: undefined`, and removing it here in this PR made the
validation around the combinations of `adapter` and `accelerateUrl`
easier.
- Fixed the incorrect error message when Accelerate URL cannot be
parsed.
Closes:
https://linear.app/prisma-company/issue/TML-1507/env-less-accelerate-url-configuration
aqrln
added a commit
that referenced
this pull request
Nov 17, 2025
This PR: - gets rid of `LibraryEngine` - gets rid of `TARGET_BUILD = 'library'` - gets rid of `binaryTargets` and `engineType` attributes in `prisma-client-js` - gets rid of outdated tests We also had to (temporarily?) disable the following tests: - **integration tests** - **client type tests** - **functional tests** - All tests when using `--generator-type prisma-client-js` - extensions/defineExtensions when using `driverAdapters` and `--remote-executor` - invalid-sqlite-isolation-level - issues/21136-extensions-mocking-library - **e2e tests** - `accelerate-types` - `unsupported-edge-error` - `connection-limit-reached` - `mongodb-notablescan` - `issues/17303-interactive-transaction-errors` - `nextjs-schema-not-found/7_monorepo-noServerComponents-noCustomOutput-noReExport` - `nextjs-schema-not-found/8_monorepo-serverComponents-noCustomOutput-noReExport` - `nextjs-schema-not-found/11_monorepo-noServerComponents-noCustomOutput-noExportIndirect` - `nextjs-schema-not-found/15` - `nextjs-schema-not-found/16` - `nextjs-schema-not-found/17` - `nextjs-schema-not-found/18` We should re-enable them in follow-up PRs. Other TODOs for follow-up PRs: - Change "chunking query" message in `packages/client-engine-runtime/src/interpreter/render-query.ts` - Figure out why functional/omit/test.ts showcases has different snapshots depending on the generator used - Test `wasm-compiler-edge` runtime --- Discoveries: - `wasm-compiler-edge` was never tested before. Adding it to the test matrix, causes failures that are out of scope for this PR. - Testing the `prisma-client-js` generator along with `prisma-client-ts` generator caused some Jest snapshots to fail. For this reason, I raised this issue internally with Alexey and temporarily stopped testing `prisma-client-js`. This should be fixed in a follow-up PR. /integration --------- Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com> Co-authored-by: Oleksii (Alexey) Orlenko <alex@aqrln.net>
aqrln
pushed a commit
that referenced
this pull request
Nov 17, 2025
This PR: - gets rid of outdated `Engine` config options. Some of these options should've probably been removed in #28375 - closes [TML-1555](https://linear.app/prisma-company/issue/TML-1555/get-rid-of-outdated-engine-config-options) --------- Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com>
aqrln
added a commit
that referenced
this pull request
Nov 17, 2025
This PR introduces a new way to configure the Accelerate URL in
preparation to removing `url` from PSL:
```ts
new PrismaClient({
accelerateUrl: "prisma://...",
})
```
This property is mutually exclusive with `adapter`, and exactly one of
them needs to be provided when using `engineType = "client"`.
It also makes a few related changes along the way or as a side effect:
- Contributes towards
[TML-1459](https://linear.app/prisma-company/issue/TML-1459/remove-processenv-loading-from-prisma-cli-and-prismaclient):
the logic related to environment variables was completely removed from
the `RemoteExecutor` code path, along with the `resolveDatasourceUrl`
function.
- Fixes the `@prisma/extension-accelerate` extension which was
inadvertently broken in #28345:
while most of `accelerateUtils` (which were meant to be used by the
removed `AccelerateEngine`) were indeed never used, one specific method
is actually currently used:
`_accelerateEngineConfig.accelerateUtils.resolveDatasourceUrl`. This PR
now restores this function and re-implements it in a different way.
- As a result of this, we now have a new validation and a DX improvement
we didn't use to: now if you apply the Accelerate extension to a client
that's not actually configured to use Accelerate, you will get a very
clear error with a code suggestion.
- Removes `null` support for the `adapter` constructor option, which was
introduced in #21315. It was the
only option that required `null` instead of `undefined` to disable it
explicitly and it was inconsistent with the others. The [motivation for
introducing `null` and making it different from
`undefined`](#21163 (comment))
made total sense for the `LibraryEngine` (where accidentally setting the
`adapter` to `undefined` meant silently using completely different
drivers before that change) but is now obsolete for the `ClientEngine`.
Since we are removing `LibraryEngine` in
#28375, we don't need this
distinction anymore since there are no longer any pitfalls from using
`adapter: undefined`, and removing it here in this PR made the
validation around the combinations of `adapter` and `accelerateUrl`
easier.
- Fixed the incorrect error message when Accelerate URL cannot be
parsed.
Closes:
https://linear.app/prisma-company/issue/TML-1507/env-less-accelerate-url-configuration
aqrln
added a commit
that referenced
this pull request
Nov 17, 2025
This PR: - gets rid of `LibraryEngine` - gets rid of `TARGET_BUILD = 'library'` - gets rid of `binaryTargets` and `engineType` attributes in `prisma-client-js` - gets rid of outdated tests We also had to (temporarily?) disable the following tests: - **integration tests** - **client type tests** - **functional tests** - All tests when using `--generator-type prisma-client-js` - extensions/defineExtensions when using `driverAdapters` and `--remote-executor` - invalid-sqlite-isolation-level - issues/21136-extensions-mocking-library - **e2e tests** - `accelerate-types` - `unsupported-edge-error` - `connection-limit-reached` - `mongodb-notablescan` - `issues/17303-interactive-transaction-errors` - `nextjs-schema-not-found/7_monorepo-noServerComponents-noCustomOutput-noReExport` - `nextjs-schema-not-found/8_monorepo-serverComponents-noCustomOutput-noReExport` - `nextjs-schema-not-found/11_monorepo-noServerComponents-noCustomOutput-noExportIndirect` - `nextjs-schema-not-found/15` - `nextjs-schema-not-found/16` - `nextjs-schema-not-found/17` - `nextjs-schema-not-found/18` We should re-enable them in follow-up PRs. Other TODOs for follow-up PRs: - Change "chunking query" message in `packages/client-engine-runtime/src/interpreter/render-query.ts` - Figure out why functional/omit/test.ts showcases has different snapshots depending on the generator used - Test `wasm-compiler-edge` runtime --- Discoveries: - `wasm-compiler-edge` was never tested before. Adding it to the test matrix, causes failures that are out of scope for this PR. - Testing the `prisma-client-js` generator along with `prisma-client-ts` generator caused some Jest snapshots to fail. For this reason, I raised this issue internally with Alexey and temporarily stopped testing `prisma-client-js`. This should be fixed in a follow-up PR. /integration --------- Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com> Co-authored-by: Oleksii (Alexey) Orlenko <alex@aqrln.net>
aqrln
pushed a commit
that referenced
this pull request
Nov 17, 2025
This PR: - gets rid of outdated `Engine` config options. Some of these options should've probably been removed in #28375 - closes [TML-1555](https://linear.app/prisma-company/issue/TML-1555/get-rid-of-outdated-engine-config-options) --------- Co-authored-by: jkomyno <12381818+jkomyno@users.noreply.github.com>
aqrln
added a commit
to prisma/prisma-engines
that referenced
this pull request
Nov 17, 2025
Remove the top level QE crates, SQL query connector and QE-specific code from `query-core`, and move the crates used by QC to the `query-compiler` directory. Also removes the Node-API specific code from `driver-adapters` and leaves only the Wasm implementation to be used by `schema-engine-wasm`. Unused MongoDB query connector is left for future reference as we are going to be porting that logic to QC. Required for #5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
Aijeyomah
pushed a commit
to Aijeyomah/prisma-engines
that referenced
this pull request
Jan 26, 2026
Remove the top level QE crates, SQL query connector and QE-specific code from `query-core`, and move the crates used by QC to the `query-compiler` directory. Also removes the Node-API specific code from `driver-adapters` and leaves only the Wasm implementation to be used by `schema-engine-wasm`. Unused MongoDB query connector is left for future reference as we are going to be porting that logic to QC. Required for prisma#5683. Closes: https://linear.app/prisma-company/issue/TML-1554/remove-query-engine-from-prisma-engines Ref: prisma/orm#28375 /prisma-branch next
nfl1ryxditimo12
added a commit
to vetching-corporation/prisma
that referenced
this pull request
May 26, 2026
…for type performance Reverts the OmitOpts generic default from `undefined` back to `Prisma.PrismaClientOptions['omit']`, restoring the optimization introduced in prisma#27777 (ORM-850) that was inadvertently changed in prisma#28375.
This was referenced May 26, 2026
aqrln
pushed a commit
that referenced
this pull request
Jun 1, 2026
…erformance (#29592) Fixes #29011 <br/> ## Problem After upgrading from Prisma 6 to 7, type checking on our production codebase (406 models, ~9,300-line schema) became effectively unusable — `tsc --noEmit` ran for over 2 minutes and `tsgo` timed out at 3 minutes, whereas it completed in ~9 seconds on v6. I traced this down to a single line change. <br/> ## Root Cause In #28375, the default value of the `OmitOpts` generic parameter on the `PrismaClient` interface was changed from `Prisma.PrismaClientOptions['omit']` to `undefined`: ```diff export interface PrismaClient< in LogOpts extends Prisma.LogLevel = never, - in out OmitOpts extends Prisma.PrismaClientOptions['omit'] = Prisma.PrismaClientOptions['omit'], + in out OmitOpts extends Prisma.PrismaClientOptions['omit'] = undefined, in out ExtArgs extends runtime.Types.Extensions.InternalArgs = runtime.Types.Extensions.DefaultArgs > { ``` This reverts the optimization from #27777 (ORM-850). The change looks unintentional — #28375 was focused on removing the library engine and doesn't mention any reason for touching the `OmitOpts` default. <br/> ## Why this causes the regression When `OmitOpts` defaults to `undefined`, every model delegate gets instantiated with `{ omit: undefined }`. Since `undefined` is structurally distinct from the constraint type (`GlobalOmitConfig | undefined`), TypeScript can't reuse cached type instantiations — it re-evaluates the full generic chain for every model x every operation. When the default matches the constraint (`= Prisma.PrismaClientOptions['omit']`), TypeScript can short-circuit the structural comparison and reuse a single cached instantiation. This is exactly how #27777 was designed to work. <br/> ## Benchmark 406 models, ~9,300-line schema. Using `tsgo --extendedDiagnostics`: | Metric | `= undefined` (current) | `= PrismaClientOptions['omit']` (this fix) | Improvement | | ------------------- | ----------------------- | ------------------------------------------ | ----------- | | Type Instantiations | 32,823,262 | 2,650,891 | **12.4x** | | Types | 6,385,830 | 1,162,723 | **5.5x** | | Memory | 4,610 MB | 2,193 MB | **2.1x** | | Check time | 16.97s | 2.47s | **6.9x** | Full project type check (`pnpm check:type`): | Tool | Before | After | | ------------ | --------------- | -------- | | `tsgo` | >3min (timeout) | **7.7s** | | `tsc` v5.9.2 | OOM / >2min | **9.0s** | I can't share the production schema (proprietary), but the numbers in #29011 from other reporters are consistent with what I'm seeing — ~30M instantiations on v7 vs ~8M on v6. <br/> ## Changes One-line fix in `packages/client-generator-ts/src/TSClient/PrismaClient.ts` — restores the original default from #27777. Note that `ClientFile.ts` already uses `Prisma.PrismaClientOptions['omit']` as the default for the public-facing export type, so this just aligns the internal interface with it. <br/> ### Type safety `PrismaClientOptions['omit']` resolves to `GlobalOmitConfig | undefined` (since `omit` is optional), which is a superset of `undefined` — so this is not a breaking change. The constructor's `OmitOpts` default is also unaffected. No runtime behavior changes.
lh0x00
pushed a commit
to lh0x00/prisma
that referenced
this pull request
Aug 9, 2026
…erformance (prisma#29592) Fixes prisma#29011 <br/> ## Problem After upgrading from Prisma 6 to 7, type checking on our production codebase (406 models, ~9,300-line schema) became effectively unusable — `tsc --noEmit` ran for over 2 minutes and `tsgo` timed out at 3 minutes, whereas it completed in ~9 seconds on v6. I traced this down to a single line change. <br/> ## Root Cause In prisma#28375, the default value of the `OmitOpts` generic parameter on the `PrismaClient` interface was changed from `Prisma.PrismaClientOptions['omit']` to `undefined`: ```diff export interface PrismaClient< in LogOpts extends Prisma.LogLevel = never, - in out OmitOpts extends Prisma.PrismaClientOptions['omit'] = Prisma.PrismaClientOptions['omit'], + in out OmitOpts extends Prisma.PrismaClientOptions['omit'] = undefined, in out ExtArgs extends runtime.Types.Extensions.InternalArgs = runtime.Types.Extensions.DefaultArgs > { ``` This reverts the optimization from prisma#27777 (ORM-850). The change looks unintentional — prisma#28375 was focused on removing the library engine and doesn't mention any reason for touching the `OmitOpts` default. <br/> ## Why this causes the regression When `OmitOpts` defaults to `undefined`, every model delegate gets instantiated with `{ omit: undefined }`. Since `undefined` is structurally distinct from the constraint type (`GlobalOmitConfig | undefined`), TypeScript can't reuse cached type instantiations — it re-evaluates the full generic chain for every model x every operation. When the default matches the constraint (`= Prisma.PrismaClientOptions['omit']`), TypeScript can short-circuit the structural comparison and reuse a single cached instantiation. This is exactly how prisma#27777 was designed to work. <br/> ## Benchmark 406 models, ~9,300-line schema. Using `tsgo --extendedDiagnostics`: | Metric | `= undefined` (current) | `= PrismaClientOptions['omit']` (this fix) | Improvement | | ------------------- | ----------------------- | ------------------------------------------ | ----------- | | Type Instantiations | 32,823,262 | 2,650,891 | **12.4x** | | Types | 6,385,830 | 1,162,723 | **5.5x** | | Memory | 4,610 MB | 2,193 MB | **2.1x** | | Check time | 16.97s | 2.47s | **6.9x** | Full project type check (`pnpm check:type`): | Tool | Before | After | | ------------ | --------------- | -------- | | `tsgo` | >3min (timeout) | **7.7s** | | `tsc` v5.9.2 | OOM / >2min | **9.0s** | I can't share the production schema (proprietary), but the numbers in prisma#29011 from other reporters are consistent with what I'm seeing — ~30M instantiations on v7 vs ~8M on v6. <br/> ## Changes One-line fix in `packages/client-generator-ts/src/TSClient/PrismaClient.ts` — restores the original default from prisma#27777. Note that `ClientFile.ts` already uses `Prisma.PrismaClientOptions['omit']` as the default for the public-facing export type, so this just aligns the internal interface with it. <br/> ### Type safety `PrismaClientOptions['omit']` resolves to `GlobalOmitConfig | undefined` (since `omit` is optional), which is a superset of `undefined` — so this is not a breaking change. The constructor's `OmitOpts` default is also unaffected. No runtime behavior changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR:
LibraryEngineTARGET_BUILD = 'library'binaryTargetsandengineTypeattributes inprisma-client-jsWe also had to (temporarily?) disable the following tests:
--generator-type prisma-client-jsdriverAdaptersand--remote-executoraccelerate-typesunsupported-edge-errorconnection-limit-reachedmongodb-notablescanissues/17303-interactive-transaction-errorsnextjs-schema-not-found/7_monorepo-noServerComponents-noCustomOutput-noReExportnextjs-schema-not-found/8_monorepo-serverComponents-noCustomOutput-noReExportnextjs-schema-not-found/11_monorepo-noServerComponents-noCustomOutput-noExportIndirectnextjs-schema-not-found/15nextjs-schema-not-found/16nextjs-schema-not-found/17nextjs-schema-not-found/18We should re-enable them in follow-up PRs.
Other TODOs for follow-up PRs:
packages/client-engine-runtime/src/interpreter/render-query.tswasm-compiler-edgeruntimeDiscoveries:
wasm-compiler-edgewas never tested before. Adding it to the test matrix, causes failures that are out of scope for this PR.prisma-client-jsgenerator along withprisma-client-tsgenerator caused some Jest snapshots to fail. For this reason, I raised this issue internally with Alexey and temporarily stopped testingprisma-client-js. This should be fixed in a follow-up PR./integration