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)

Most upvoted comments

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.

Can you try out if giving your Clients a different output outside of node_modules and the existing @prisma/client package solves this problem? As this location is potentially interfering with the normal package, this might be the cause here.

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:

    "./core": {
      "types": "./core/default.d.ts",
      "require": "./core/default.js",
      "import": "./core/default.js",
      "default": "./core/default.js"
    },

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 service

Unfortunately, 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 below

generator client {
  provider = "prisma-client-js"
  output   = "../node_modules/@prisma/client/test"
}

I have got the problem.

But If I put the the client in a different folder like @my-firm/client the problem go away

generator client {
  provider = "prisma-client-js"
  output   = "../node_modules/@my-firm/client/test"
}

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

2024-02-06 16:42:12.094] error: uncaughtException: Cannot find module '/Users/joanortega/workspace/app.theglue.bloomays/node_modules/@prisma/client/api-bloomers'
Error: Cannot find module '/Users/joanortega/workspace/app.theglue.bloomays/node_modules/@prisma/client/api-bloomers'
    at createEsmNotFoundErr (node:internal/modules/cjs/loader:1070:15)
    at finalizeEsmResolution (node:internal/modules/cjs/loader:1063:15)
    at resolveExports (node:internal/modules/cjs/loader:547:14)
    at Function.Module._findPath (node:internal/modules/cjs/loader:621:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:1034:27)
    at Module.Hook.Module.require (/Users/joanortega/workspace/app.theglue.bloomays/node_modules/dd-trace/packages/dd-trace/src/ritm.js:54:29)
    at require (node:internal/modules/helpers:130:18)
    at Array.Object.defineProperty.value (/Users/joanortega/workspace/app.theglue.bloomays/dist/packages/api.bloomers/webpack:/external commonjs "@prisma/client/api-bloomers":1:1)
    at __webpack_require__ (/Users/joanortega/workspace/app.theglue.bloomays/dist/packages/api.bloomers/webpack:/webpack/bootstrap:19:1)
    at Array.<anonymous> (/Users/joanortega/workspace/app.theglue.bloomays/dist/packages/api.bloomers/webpack:/src/database/prisma/prisma-client.ts:1:1)

and I have a similar configuraition for generator client

generator client {
  provider = "prisma-client-js"
  output        = "../../../../../node_modules/@prisma/client/api-bloomers"
  engineType    = "binary"
  binaryTargets = ["debian-openssl-1.0.x", "debian-openssl-1.1.x", "debian-openssl-3.0.x", "linux-musl", "linux-musl-openssl-3.0.x", "darwin-arm64"]
}

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

(/Users/joanortega/workspace/app.theglue.bloomays/dist/packages/api.bloomers/webpack:/external commonjs "@prisma/client/api-bloomers":1:1)

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 in tsconfig.json 😕

Because in that case it is a convenient shortcut we thought would be smart back in the day: The generated Client is put in node_modules/.prisma/client (note the ., it’s not @prisma/client so it does not interfere with the actual @prisma/client package) - and you then can just import via @prisma/client - which actually loads the files from .prisma/client there instead.

@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 😃

Thanks for the recommendation. Is that the best practice? Should we keep the @prisma-clients/{service} in node_modules?

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?