prisma: Prisma not working with sst monorepo

Bug description

SST is a framework to build serverless applications on aws and with the update to version 2.0 switched to a monorepo setup. Pre 2.0 it worked fine with prisma but since version 2.0 i ran into similar problems than other users have with nextjs.

They have an example setup with prisma where they have already a workaround applied to copy the prisma engines to the correct locations. This worked before v2.0 but now additional problems arise due to sst being a monorepo.

I already posted an issue on the sst git, but, as it is essentially a problem of prisma working with monorepos i decided to post it here aswell.

How to reproduce

  • Create an sst project using: yarn create sst --template=examples/prisma
  • run yarn install
  • run yarn run dev // deploys lambdas structure to aws
  • Response when running a lambda that accesses a prismaClient instance:
ReferenceError: __filename is not defined
|  +290ms      at Object.resolveEnginePath (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:99:280)
|  +291ms      at Object.getLibQueryEnginePath (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:73:1125)
|  +291ms      at Object.loadLibrary (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:73:561)
|  +291ms      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
|  +291ms      at Object.loadEngine (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:101:557)
|  +291ms      at Object.instantiateLibrary (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:100:1477)
|  +291ms      at Object.start (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:101:2081)
|  +291ms      at Object.getDmmf (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:101:3489)
|  +291ms      at <anonymous> (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:177:2864)
|  +291ms      at <anonymous> (/projects/test/prisma-test/node_modules/@prisma/client/runtime/library.js:177:3294) {
|  +291ms    clientVersion: '4.12.0'
|  +291ms  }
  • response when running the project in a production environment (not SST’s lambda live dev) and accessing a function that accesses a prismaClient instance:
2023-03-29T15:10:57.786Z	undefined	ERROR	Uncaught Exception 	{
    "errorType": "Error",
    "errorMessage": "ENOENT: no such file or directory, open '/var/task/services/api/functions/schema.prisma'",
    "code": "ENOENT",
    "errno": -2,
    "syscall": "open",
    "path": "/var/task/services/api/functions/schema.prisma",
    "clientVersion": "4.12.0",
    "stack": [
        "Error: ENOENT: no such file or directory, open '/var/task/services/api/functions/schema.prisma'",
        "    at Object.openSync (node:fs:590:3)",
        "    at Object.readFileSync (node:fs:458:35)",
        "    at new LibraryEngine (file:///var/task/services/api/functions/index.mjs:29805:39)",
        "    at t3.getEngine (file:///var/task/services/api/functions/index.mjs:33428:20)",
        "    at new PrismaClient (file:///var/task/services/api/functions/index.mjs:33410:1118)",
        "    at file:///var/task/services/api/functions/index.mjs:58864:14",
        "    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)",
        "    at async Promise.all (index 0)",
        "    at async ESMLoader.import (node:internal/modules/esm/loader:530:24)",
        "    at async _tryAwaitImport (file:///var/runtime/index.mjs:917:16)"
    ]
}

With prisma.schema copied to var/task/services/api/functions -> resolveEnginePath function of prisma accesses __filename which is not defined…

2023-03-29T15:29:12.684Z	fd320ee1-d78a-4e81-afe5-98f92c7e65ec	ERROR	ReferenceError: __filename is not defined
    at Object.resolveEnginePath (file:///var/task/services/api/functions/index.mjs:29737:58)
    at Object.getLibQueryEnginePath (file:///var/task/services/api/functions/index.mjs:29693:68)
    at Object.loadLibrary (file:///var/task/services/api/functions/index.mjs:29679:107)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Object.loadEngine (file:///var/task/services/api/functions/index.mjs:29865:58)
    at async Object.instantiateLibrary (file:///var/task/services/api/functions/index.mjs:29837:63)
    at async Object.start (file:///var/task/services/api/functions/index.mjs:29908:13)
    at async Object.getDmmf (file:///var/task/services/api/functions/index.mjs:29939:9)
    at async file:///var/task/services/api/functions/index.mjs:33385:24
    at async file:///var/task/services/api/functions/index.mjs:33391:186 {
  clientVersion: '4.12.0'
}

Environment & setup

  • OS: Debian
  • Database: MySql
  • Node.js version: 18.15.0

Prisma Version

4.12.0

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 21
  • Comments: 34 (12 by maintainers)

Most upvoted comments

@janpio I just did reproduce it on the repo, kindly check and let me know if I could help in any other way. thanks. Screenshot 2023-11-01 at 19 14 38

public lambda url link

https://lvmbcw4u7vdbsyx6bxc6zgvx2e0ftxfo.lambda-url.us-east-1.on.aws/

hopefully if the part where I copy files over is correct, it could be documents so people could easily find it.

copyFiles: [
  {
    from: "packages/functions/prisma/schema.prisma",
    to: "packages/functions/src/schema.prisma",
  },
  {
    from: "packages/functions/node_modules/prisma/libquery_engine-linux-arm64-openssl-1.0.x.so.node",
    to: "packages/functions/src/libquery_engine-linux-arm64-openssl-1.0.x.so.node",
  },
],

update

@janpio

after adding this to my function config

  nodejs: { esbuild: { external: ["@prisma/client", ".prisma"] } },

I got it working locally.

Screenshot 2023-11-01 at 19 40 49

however it does not work after deployment… ( Internal server error )

Screenshot 2023-11-01 at 19 44 23

could this be a pnpm symlink issue ? @millsp @janpio

@janpio I think I got it work … finally. I will leave the repo up for reference.

this repo was also very helpful https://github.com/geauser/sst-prisma-example

I had the same problem. Based on the following example, I performed some Prisma-related changes in our project, which worked out.

SST Prisma example

The issue comes from the engine binary resolution. https://github.com/prisma/prisma/blob/7aac24cb0fdb7e10aea5cfc59df3fc951fd93212/packages/client/src/runtime/core/engines/common/resolveEnginePath.ts#L100

You can skip the resolution by providing the value statically via PRISMA_QUERY_ENGINE_LIBRARY / PRISMA_QUERY_ENGINE_BINARY environment variable.

As long term fix maybe the filename should be loaded via eval('__filename')? The solution seems to work for the dirname a few lines above https://github.com/prisma/prisma/blob/7aac24cb0fdb7e10aea5cfc59df3fc951fd93212/packages/client/src/runtime/core/engines/common/resolveEnginePath.ts#L90

but if you would like I could try.

Yes please do, although we know why this is happening (as Pierre posted) we need a clear reproduction that we can try to fix this and confirm it is fully fixed and does not just uncover the next problem.

yes we do, we have not been able to use prisma for sst for a while now. I’ll try to make a minimal reproducible example for you today. would that help ?

Any update on this as we’re upgrading a project from sst v1 to v2 and are now running into this issue as well…