prisma: `Error: Cannot find module ... at createEsmNotFoundErr (node:internal/modules/cjs/loader:1181:15)`
Bug description
After update to
prisma : 5.9.1
@prisma/client : 5.9.1
Computed binaryTarget : windows
Operating System : win32
Architecture : x64
Node.js : v20.10.0
Query Engine (Node-API) : libquery-engine 23fdc5965b1e05fc54e5f26ed3de66776b93de64 (at node_modules\@prisma\engines\query_engine-windows.dll.node)
Schema Engine : schema-engine-cli 23fdc5965b1e05fc54e5f26ed3de66776b93de64 (at node_modules\@prisma\engines\schema-engine-windows.exe)
Schema Wasm : @prisma/prisma-schema-wasm 5.9.0-32.23fdc5965b1e05fc54e5f26ed3de66776b93de64
Default Engines Hash : 23fdc5965b1e05fc54e5f26ed3de66776b93de64
Studio : 0.497.0
I receive this error
Error: Cannot find module 'C:\test\node_modules\@prisma\client\test\default'
at createEsmNotFoundErr (node:internal/modules/cjs/loader:1181:15)
at finalizeEsmResolution (node:internal/modules/cjs/loader:1169:15)
at resolveExports (node:internal/modules/cjs/loader:591:14)
at Function.Module._findPath (node:internal/modules/cjs/loader:668:31)
at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1130:27)
at Function.Module._load (node:internal/modules/cjs/loader:985:27)
at Function.Module._load (C:\test\node_modules\@nx\js\src\executors\node\node-with-require-overrides.js:18:31)
at Module.require (node:internal/modules/cjs/loader:1235:19)
at require (node:internal/modules/helpers:176:18)
at Object.<anonymous> (C:\test\apps\test\src\main.ts:23:38)
it seem that https://github.com/prisma/prisma/issues/22875 not resolve it 😦
I suspect that the problem is with the generation, in particulary I generate the client in differente place, my schema prisma is
generator client {
provider = "prisma-client-js"
output = "../node_modules/@prisma/client/test"
}
and I import the client as
import { Prisma, PrismaClient } from '@prisma/client/test';
as you suggest in the docs
could be this the problem?
About this issue
- Original URL
- State: open
- Created 5 months ago
- Reactions: 4
- Comments: 30 (7 by maintainers)
Regarding my previous post: I am aware that what I am describing is not a prisma issue, just wanted to share the consequences I am facing.
If I come up with a nice solution, I’ll share it here as well.
Moving clients to
node_modules/@prisma-clients/{service}
folders works.So you’re right, the problem is interfering with a normal package introduced in v5.9 by adding an
exports
block in@prisma/client/package.json
. Unfortunately, wildcard"./*": "./*"
does not help here as well, on the other hand, adding correct paths, for example:solves the issue (just for note, not a good workaround 😅) .
We faced the same issue after upgrading to 5.9/5.10
@janpio, RE: your question about motivation: We’re using
@prisma/client/{serviceName}
because our project is monorepo with 10+ services with their own DBs, some services can access foreign databases for read operations, that’s why we need to have clients scoped in respective folders for services. Basically, since the default path of the Prisma client was@prisma/client
we decided to utilize it by adding a subfolder for each serviceUnfortunately, for now, we’re limited in version upgrading because client generation is broken. Please, let me know if there is anything I could assist you
Hi to all, today I’ve investigate a little forward about this bug.
I’ve notice that if I put the client inside
@prisma/client
node_modules folder, like belowI have got the problem.
But If I put the the client in a different folder like @my-firm/client the problem go away
I hope that in this way you can replicate the annoing glich
Confirmed that if you do not have
"type": "module"
in package.json, we get the same error saying it cannot find the module. Reverting to v5.8.0 fixes it.I’m having similar issue after upgrading prisma from 5.3.0 to 5.9.1
and I have a similar configuraition for
generator client
I can see the files copied in the right folder, but still having the error… Isn’t it related to a commonjs format of the files ? I don’t know how to interpret this part of the stack
I‘ve now tried moving the clients out of node_modules. With the new setup, I also implemented the prisma client as a nx library. Importing now works using
import … from '@foo/prisma-client-bar'
. But now I am presented with an unexpected issue 😅We are importing one of our prisma-clients in in our global-setup in some libraries, and apparently jests globalSetup files do not respect the
paths
configured intsconfig.json
😕@janpio But don’t you think it make sense to have similar best practices for having one client and for having multiple clients?
If the plan is to move away from
node_modules/.prisma/client
for the default, I agree that it makes sense to drop support for multiple clients in there. But if you want to keep it for one client, my personal opinion would be that it’s a bug if it does not work for multiple clients anymore.These are just my two cents, hopefully they help 😃
I don’t see any issues with this approach
We don’t know if there is a fix right now, or if fixing this is really in our best interest. Is there a reason why you prefer the current naming schema although it modifies the Prisma Client package?