prisma: Upgrade from 4.12 to 4.15: Prisma can no longer find schema.prisma file when launching Electron packaged executable

@millsp

Had to do something similar to @lemonpole (CopyWebpackPlugin) to get this to work. Some notes:

1. Electron runs locally via 2 processes - renderer & main, roughly analogous to client and server respectively for a traditional web app.
2. Prisma client will be part of “main” process.
3. When electron executable is run, relevant files are moved to users “appdata/local/temp” directory.
4. Electron uses ASAR to archive source code: https://www.electronjs.org/docs/latest/tutorial/asar-archives
5. Therefore “__dirname” will resolve to something like this: “C:\Users\dfoley\AppData\Local\Temp\2TRA7lffeULjLnokr688C8Hj9Fx\resources\app.asar\dist\main” … this is the directory of the “main” process.
6. The schema.prisma file will actually be at “C:\Users\dfoley\AppData\Local\Temp\2TRA7lffeULjLnokr688C8Hj9Fx\resources\app.asar\dist\main\db\generated”
7. You get close with your “alternativePaths” attempt, but you join these to process.cwd(). In my case this resolves to: “C:\Users\dfoley\AppData\Local\Temp\2TRA7lffeULjLnokr688C8Hj9Fx” - i cant say i understand why this the case.

The reason this used to work (4.12) is you used “findSync” to find the same “alternatePaths” under the cwd. However, findSync() looked for the alternatePaths as patterns under the cwd, rather than literal paths =>“main\db\generated\schema.prisma” was found somewhere in the cwd. Unless you think it’s a good idea regressing to matching patterns again, I think slightly hacky web packing like @lemonpole and I have done might be simplest.

Hey @janpio I’ve created a boilerplate repo based off of my private project which is where I am facing the issue.

https://github.com/lemonpole/electron-forge-prisma

It has two branches:

• The stable main branch where you can see things working as expected using prisma@4.9.x.
• The build/prisma-upgrade branch where it is possible to reproduce the issue.

The application renders a countries dropdown which is populated using Prisma backed by SQLite3.

I hope this helps, and disclaimer, I’ve only tested this on Windows.

# development
npm install
npm start

# production
npm run make

After building the production bundle you can open it using:

"out\alpha\Electron Forge Prisma-win32-x64\Electron Forge Prisma.exe"

Thanks @dfoley-greenlight and @lemonpole, this is really helpful information.

@millsp Will try to give feedback today, tomorrow at latest

Hey @millsp yes that is correct.

I’ll defer to OP on confirming whether the fix worked for them as their issue seems genuine.

Whereas mine, I’ve come to realize, is due to a limitation with Electron Forge and how it handles extraneous files by placing them in a nested resources directory.

Also, thanks a lot for your reply, it’s invaluable for me to be able to understand these problems better and improve things down the line.

Hey @millsp thanks so much for the quick turnaround on this. It did not work for me, unfortunately, but after messing with my build system today (thanks to your update) I was able to come up with a sufficient workaround.

To sum up, (and for anybody else who stumbles upon this issue), Electron Forge is placing the schema.prisma file under a nested resources directory. Apparently, the Electron packaging tool only picks up extra files under this directory. So it’s more a limitation with Electron Forge than an issue with Prisma itself, so I’m satisfied with the fix.

# expected
%LOCALAPPDATA%/<app>/.prisma/client

# actual
%LOCALAPPDATA%/<app>/resources/.prisma/client

Using CopyWebpackPlugin I’m able to copy it to the expected location.

 plugins: [
  new CopyPlugin({
    patterns: [{ from: './node_modules/.prisma/client' }],
  }),
],

I will work on pushing these changes to the reproduction repo along with attempting to add some basic support for Linux.