feat(prisma): support the new `prisma-client` generator

[Romakita]

User story

As an @tsed/prisma user adopting Prisma's modern prisma-client generator,
I want to generate Ts.ED models, repositories, and services from a Prisma Client generated to an explicit directory,
so that I can migrate to recent Prisma versions without retaining prisma-client-js as a compatibility dependency.

Context

Source discussion: https://github.com/orgs/tsedio/discussions/3449

Prisma recommends the prisma-client provider and states that prisma-client-js will be removed in a future Prisma ORM release. The new provider requires an explicit output and generates the client outside node_modules.

The workspace already uses Prisma 7.3.0 to develop @tsed/prisma, but the integration cannot yet consume this new provider.

Product decision

Supporting both Prisma client providers is not a requirement if the resulting implementation or maintenance burden is significant.

The implementation should first assess the cost of keeping prisma-client-js compatibility:

• If it is small and does not introduce fragile conditional behaviour, support both providers during a transition.
• If it is substantial, release a new major version of @tsed/prisma that supports only prisma-client.

In the Prisma-client-only option:

• The migration must be clearly documented, including the required output and import-path changes.
• Configuring prisma-client-js must fail early with an explicit error explaining that it is unsupported and how to migrate.
• Do not silently rewrite or strip -js from the configured provider; an automatic transformation could conceal an invalid schema and yield surprising output.

Impact analysis

Current blockers

• packages/orm/prisma/src/generator.ts declares requiresGenerators: ["prisma-client-js"], so Prisma still requires the legacy generator.
• packages/orm/prisma/src/cli/prismaGenerator.ts exclusively looks up a generator whose provider is prisma-client-js; with provider = "prisma-client", that lookup finds nothing and generation fails.
• The client path is derived from otherGenerators and the implementation assumes output is present. This must be validated against the new provider's required explicit output.
• Generated imports—especially Prisma.Decimal—must keep working with a locally generated ESM client and must not silently fall back to @prisma/client.

Areas to validate

• Prisma generator contract: @prisma/generator-helper, @prisma/internals, GeneratorOptions, and DMMF.
• Import resolution for generated models, the Prisma namespace, enums, and scalar types.
• ESM output and relative paths, including any required extensions for the selected generation mode.
• The measured cost and reliability of retaining prisma-client-js compatibility.
• Existing fixtures: PostgreSQL ESM, Mongo ESM, enums, and circular references. Prisma's v7 documentation notes that MongoDB is not supported in v7; therefore, the test strategy must distinguish legacy compatibility from the modern Prisma compatibility matrix.

Proposed scope

1. Accept prisma-client as a supported provider in both the manifest and the onGenerate phase.
2. Safely resolve the configured client generator and its output, with an actionable error when no compatible provider or output is configured.
3. Propagate the actual client path to every transformation that generates imports.
4. Assess legacy prisma-client-js support and select one of the documented migration paths below.
5. Update integration documentation with a schema.prisma example using prisma-client and a local output.
6. Prepare the compatibility matrix for the current Prisma major version. Prisma 8 support must be validated separately against its connector-specific migration guides.

Migration paths

A. Low-impact transition

Maintain both prisma-client and prisma-client-js, with regression tests for both providers.

B. Preferred when dual support is costly

Ship a new major version of @tsed/prisma supporting only prisma-client; document the migration and reject prisma-client-js with an explicit diagnostic.

Acceptance criteria

• A configuration with generator client { provider = "prisma-client"; output = "../generated/prisma" } and generator tsed { provider = "tsed-prisma" } runs prisma generate successfully.
• Generated Ts.ED models compile and correctly import the Prisma client—including Prisma.Decimal—from a custom output.
• Generated imports are valid in ESM.
• The implementation records the chosen migration path and its rationale.
• If path A is chosen, a legacy prisma-client-js configuration remains functional and is covered by non-regression tests.
• If path B is chosen, the release is a new @tsed/prisma major version; documentation provides the migration steps; and prisma-client-js fails with an explicit, actionable error.
• The implementation never silently converts prisma-client-js to prisma-client.
• Integration tests cover at least scalar models/enums, circular references, and a custom client output.
• Error messages clearly identify the expected provider and a missing output.
• The @tsed/prisma documentation describes the recommended configuration and Prisma compatibility status.

Out of scope

• Changing Prisma connection configuration (prisma.config.ts, datasource URLs, or driver adapters) unless required to run the tests.
• Claiming complete Prisma 8 compatibility without executing a dedicated validation matrix.

Planned validation

• Run the focused packages/orm/prisma test suite.
• Run prisma generate against the new prisma-client fixture.
• Type-check generated artifacts.
• Run applicable existing ESM fixtures.
• If legacy support is retained, run the equivalent prisma-client-js fixture.

[github-actions]

🎉 Are you happy?

If you appreciated the support, know that it is free and is carried out on personal time ;)

A support, even a little bit makes a difference for me and continues to bring you answers!

[Romakita]

🎉 This issue has been resolved in version 8.40.0 🎉

The release is available on:

• v8.40.0
• GitHub release

Your semantic-release bot 📦🚀