Support multi-file Prisma Schema/Contract in Prisma 8

[zalaghi-dev]

What problem are you trying to solve?

In Prisma 7, we can organize large Prisma schemas across multiple .prisma files using the multi-file schema feature.

For example:

prisma/
├── schema/
│ ├── schema.prisma
│ ├── user.prisma
│ ├── project.prisma
│ ├── task.prisma
│ └── comment.prisma
└── migrations/

This is especially useful for large projects with dozens or hundreds of models, where keeping everything in a single file becomes difficult to navigate and maintain.

In Prisma 8, the new contract-based architecture currently expects a single contract source:

contract: "./prisma/contract.prisma"

This means that the previous multi-file .prisma organization is no longer available when using PSL as the contract authoring format.

I understand that Prisma 8 provides a TypeScript contract builder that can split and compose model definitions across TypeScript modules. However, requiring users to migrate their existing Prisma Schema Language models to TypeScript just to keep a multi-file structure feels like an unnecessary trade-off.

Feature request

Please consider bringing multi-file Prisma Schema Language support to Prisma 8 contracts.

For example:

prisma/
├── contract/
│ ├── contract.prisma
│ ├── user.prisma
│ ├── project.prisma
│ ├── task.prisma
│ └── comment.prisma
└── migrations/

Or something similar to the existing Prisma 7 multi-file schema behavior.

The goal would be for Prisma 8 to treat all .prisma files within the configured contract directory as a single contract, while still emitting the same:

contract.json
contract.d.ts
Why this matters

For small projects, a single contract.prisma file is perfectly reasonable.

For large applications, however, a single file can become very difficult to maintain. Domain-based organization is much easier to work with:

auth/
user.prisma
role.prisma
permission.prisma

projects/
project.prisma
project-member.prisma

tasks/
task.prisma
task-comment.prisma
task-label.prisma

This also makes it easier to:

navigate large schemas
separate domains
review changes in pull requests
reduce merge conflicts
maintain large NestJS applications
migrate existing Prisma 7 projects to Prisma 8 without restructuring the entire data layer
Expected behavior

I would like to be able to configure something along the lines of:

export default definePrismaConfig({
orm: ormConfig({
contract: "./prisma/contract",
}),
});

and have Prisma automatically load all .prisma files in that directory as a single PSL contract.

This would preserve the existing Prisma Schema Language workflow while making it compatible with the new Prisma 8 contract architecture.

Thanks for considering this. Multi-file schema support was extremely valuable for large Prisma projects, and having the same capability in Prisma 8 would make migration to the new architecture much easier.

Proposed solution

Allow Prisma 8 contracts written in Prisma Schema Language (.prisma) to be split across multiple files, similar to the multi-file schema support available in Prisma 7.

For example:

prisma/
├── contract/
│   ├── schema.prisma
│   ├── user.prisma
│   ├── project.prisma
│   ├── task.prisma
│   └── comment.prisma

When the contract path points to the contract/ directory, Prisma should automatically discover and combine all .prisma files into a single contract.

This would preserve the existing Prisma Schema Language workflow while allowing large projects to organize models by domain without having to migrate their schemas to the TypeScript Contract Builder.

Ideally, the generated contract should behave exactly like a single .prisma contract from Prisma 8, including relations, enums, indexes, and other schema definitions across files.

Alternatives considered

No response

Scope and impact

No response

[Shgit29]

@SevInf I dug into the current Prisma ORM v8 contract-loading path and confirmed this is currently unsupported.

A directory contract path is accepted by config validation and resolved normally, but the built-in PSL providers still consume exactly one input and eventually call readFile() on the directory, which fails with EISDIR.

I also tested the simple concatenation approach. Cross-file model relations resolve correctly once the files are combined, but diagnostics lose the original filename and source-local line numbers because the PSL stack currently works with one DocumentAst, one SourceFile, one symbol table, and one sourceId.

Prisma 7’s multi-file loader looks reusable conceptually for directory discovery, but its cross-file semantic resolution lived in the old schema engine.

A cleaner Prisma ORM v8 direction seems to be a small multi-source PSL abstraction: parse each .prisma file independently, preserve its sourceId / SourceFile, then build a global symbol table across those source units before interpretation.

Before implementing, I’d like to confirm a few design points:

• Should directory discovery be recursive like Prisma 7?
• Should files be sorted by normalized relative path for deterministic behavior?
• Should SQL and Mongo support land together?
• Is a reusable multi-source PSL/source-set abstraction the preferred direction, or would source-mapped concatenation be acceptable initially?
• For a directory contract, should the default output remain inside that directory as contract.json?

Happy to work on this once the intended direction is confirmed.