Why Prisma ORM Generates Code into Node Modules & Why It’ll Change

Why Prisma ORM generates code Prisma Client into node_modules

Since its initial release, Prisma ORM has been using code generation to generate a database client (called "Prisma Client") that's tailored to a database schema. The Prisma Client library is auto-generated based on the Prisma schema so that it's aware of their structure and can provide custom, type-safe queries for them.

Code generation is not the most conventional method in the TypeScript ecosystem and Prisma ORM was one of the first popular libraries to rely on it. In order to maximize familiarity for developers, we decided to generate Prisma Client into the node_modules folder by default because that's how they're used to integrate 3rd party libraries in their applications.

While it was possible from the beginning to choose a custom location for the generated code via the output field, this default gave us a unified behavior across various frameworks and usage contexts of Prisma ORM:

Generating Prisma Client into node_modules by default ultimately led to a magical "it just works™️" developer experience for most people … except, when it didn't!

Why and how are we changing the location of Prisma Client in v7

Since then, developers encountered problems due to the generated code in node_modules. Many tools across the JS/TS ecosystem operate under the assumption that the node_modules directory won't be modified—except by your package manager (npm, pnpm, yarn etc).

However, with Prisma ORM, you need to re-generate Prisma Client after every database schema change so that the generated code reflects the latest state of your database. This requirement along with the default choice of putting generated code into node_modules violated the assumption of many tools in the ecosystem.

Required workarounds when putting generated code into node_modules

Because many tools operate under the assumption that node_modules is only modified by a package manager, we (and others in the community) put in place workarounds to ensure a smooth DX.

For example, because the TS language server doesn't watch for changes in node_modules, we adjusted the Prisma VS Code extension to reboot the TS language server any time you run prisma generate. Another example is the @prisma/nextjs-monorepo-workaround-plugin package whose sole purpose is to ensure that files are copied properly from node_modules when Prisma ORM is used in monorepos with Next.js.

Workarounds for the core issue of the generated code living in node_modules exist in various shapes and forms, from dedicated packages to hardcoded code paths.

What is changing going forward?

While the initial decision of generating Prisma Client into node_modules helped a lot of developers getting started and provided a smooth, unified DX, we also saw that this kind of "magical" behavior often led to unexpected problems when developers were using Prisma ORM.

We are currently in the process of making the DX of using Prisma ORM simpler and more predictable by removing magical behavior or unnecessary abstraction layers.

As part of this initiative, we are going to remove the option to generate code into node_modules by always requiring an output path.

To anticipate this change, we added a deprecation warning in v6.6.0 and changed our documentation. This has caused some unnecessary confusion in the community, read more about that in the next section.

This change will come later this year as part of Prisma ORM v7 and only affect the new prisma-client generator. There are several benefits to this approach:

• The generated code will be treated like "regular" application code: developers will have full control over it and can decide how it's going to be part of their application bundle.
• More predictability and no more workarounds due to magical behavior.
• Compliance with the assumption that node_modules can only be modified by package managers.

prisma-client vs prisma-client-js generators

If you've followed our releases, you know that in v6.6.0 we released a new generator, called simply prisma-client:

This new generator supports ESM, is compatible with various JS runtimes, overall is more flexible, and requires the custom output path.

In Prisma ORM v7, it will become the default generator to be used with Prisma ORM and the current prisma-client-js generator (with the magical node_modules generation) will be put in maintenance mode.

Confusions with setting an output path since v6.6.0

To anticipate the upcoming changes in v7, we wanted to help developers prepare for the breaking change of a required output path by nudging them to not rely on generating Prisma Client into node_modules any more.

So, in the recent v6.6.0 release, we introduced the following deprecation warning in the Prisma CLI output when you were not using a custom output path with the prisma-client-js generator:

We also changed the default generated Prisma schema that was generated when running prisma init to include an output path and updated our documentation accordingly.

While we expected this nudge to only have positive effects due to the removal of unpredictable, problematic behaviors and giving more control to developers, a lot of people actually reported issues after they saw the deprecation warning and switched to using a custom output path with the prisma-client-js generator.

Users started reporting linting failures in src/generated/prisma, particularly problematic with e.g. the Next.js dev server which halts operations if linting errors are detected. Since the code is generated, linting errors don't really matter, but users didn't by default have src/generated excluded from their linting config.

Other users reported issues with their bundlers, relative path resolution, and a host of other unintended side effects. Overall, we saw a lot of confusion around where to generate Prisma Client and how to bundle it.

All this happened on projects that had been working fine when Prisma Client lived in node_modules. To avoid these kinds of issues until v7, we are removing the deprecation warning from the CLI output again and will be fixing the issues that have been raised by the community.

When to use a custom output path with Prisma ORM today

Here's a TLDR for what all of this means for you today:

• If you have an existing project with Prisma ORM and are using the prisma-client-js generator:
  • If you recently added a custom output path and saw errors due to that change, you can revert back to generating Prisma Client into node_modules as you did before.
  • If Prisma ORM is working for you today while generating Prisma Client into node_modules, there's no reason to change anything. Prisma ORM v7 will introduce the new prisma-client generator as the default way for using Prisma ORM with an output path. When the time comes, there will be comprehensive documentation for your upgrade paths.
• If you start with a new project today, we recommend setting a custom output path to avoid bundling issues and prepare for the upcoming breaking changes in Prisma ORM v7. Since the generated assets are (mostly) source code, which is intended to be processed and included in your application's bundle, we suggest using a path within your application source tree (e.g. src/generated/prisma).
• If you experience issues with an output path (regardless of whether you use the new prisma-client or the current prisma-client-js generator), please open a new issue so we can help you resolve the problem.

As always, reach out to us on X or join our Discord if you have any feedback or questions!