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)
@janpio I just did reproduce it on the repo, kindly check and let me know if I could help in any other way. thanks.
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.
update
@janpio
after adding this to my function config
I got it working locally.
however it does not work after deployment… ( Internal server error )
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#L90Yes 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…