Is this a bad Idea? Transition to Rust Free, Using TS Paths to override old @prisma/client imports
We have 939 files that are importing "@prisma/client".
Ideally we will be refactoring all 939 files for example So my interim solution is to use typescript paths to override the old
Ideally we will be refactoring all 939 files for example So my interim solution is to use typescript paths to override the old
@prisma/client to my generated output. (I feel like the node_modules/.prisma/clientcould be pointing to this for backwards compatibility)
and adding an eslint rule for "no-restricted-imports"
How insane is what I'm doing?
Side note... I had an AI help me with a codemod for changing the Prisma.validator implementations to be satisfies instead which counts for (209 of these 939 files)4 Replies
You've gone full bot mode! Let me fetch that AI answer for you ASAP.
Your approach—using TypeScript paths to alias @prisma/client to your generated output—is a practical interim solution, especially when you have a large codebase with many imports to refactor. This method is explicitly mentioned as a valid workaround in the Prisma community for cases where you move the generated client out of node_modules, and it allows you to avoid breaking all existing imports at once. The Prisma team and users have used this approach to maintain compatibility during transitions, and it is not considered "insane"—just a pragmatic step for large-scale migrations see example.
However, there are a few caveats:
- This is a workaround, not a long-term best practice. The Prisma team recommends importing directly from your generated client path once you move away from node_modules, as the generated code is now treated as your own application code and not a package see comment.
- Using TS paths for this purpose can sometimes cause confusion for new team members or tooling that expects @prisma/client to be a real npm package.
- You should ensure your generated directory is excluded from version control, as it contains binaries and machine-specific files see docs.
Your eslint rule is a good way to enforce the new import style and help with gradual migration.
In summary: your approach is reasonable for a large codebase in transition, and is used by others in the community. Just plan to eventually update all imports to the new path for clarity and maintainability. There is no indication in the knowledge sources that this would cause major issues, but be aware of the limitations and eventual need to fully migrate your imports.
That https://github.com/prisma/prisma/issues/27169 was really useful because it means I'm not the only person to consider this as a solution. Thanks.
GitHub
Import errror from @prisma/client with client output defined · Iss...
Bug description I have updated prisma to the latest version and configured an output path for the generated client code as suggested. However, the automatic export of the generated types does not w...
✅ Great, thanks for letting us know that this solved your question!
I would recommend creating an export file, effectively implementing the "facade pattern", so that all your imports point to a file you control, instead of directly from the library.
For example you could make a
db.ts file which simply re-exports the imports you need across your application.
That's a more direct path and likely lead to fewer edgecase issues.
Additionally, to easen your transition, you could do a codebase wide search for the import "@prisma/client"; and do a replace with your new export file.