[Next.js + Now serverless] Can't resolve 'child_process' in './node_modules/@prisma/photon/runtime'

[Albert-Gao]

I am using preview019 with a SQLite db

Photon sits in a file and being used everywhere

import { Photon } from "@prisma/photon";

export const photon = new Photon();

The initialization caused the problem if I change that to something like export const photon = 123;, then this error goes away.

Maybe I get the initialization wrong? Should not reuse this instance?

The project is next.js v9, api is Now serverless, sits in pages/api

After running next, the 1st render to index works, but go to any page will show the following error:

However, api is working: /api/graphql is working:

anything to do with #1021 ?

[Albert-Gao]

Dropping Prisma2 and Photon to preview018 (remove node_modules, package-lock.json, and using absolute version number: 2.0.0-preview018), same error

[Albert-Gao]

Found a similar issue but not sure: vercel/next.js#7334

[Albert-Gao]

It seems to be solved by not reuse the instance but create a new one every time I need to use it like this const photon = new Photon();

[Albert-Gao]

It blows my mind, I still reuse the instance, but put the file into the project root rather than /utils, still works...

Maybe it has something to do with the way I import it, previously, I put it inside /utils/photon.ts and export it in /utils/index.ts , so I can import {photon} from '../utils' , this causes the problem

[Albert-Gao]

As long as I import the photon instance from the file it sit directly in, rather than from a index.ts , everything works.

[pantharshit00]

I think it has to do with how next js is bundling file(I am not familiar with the internals of that library).

Next is bundling photon when it is split out in a sperate file. Photon depends on child_process which is a native node js package and it is not available in the browser.

I'd suggest opening an issue in the next repo about this.

[smakosh]

Having the same issue when using getServerSideProps

[guillaumeLamanda]

I here 👋

I made a minimal reproduction of the child_process error with Next.js.
https://github.com/guillaumeLamanda/nextjs-prisma

Hope it can help

[pantharshit00]

@guillaumeLamanda This is expected. The dependencies inside next js getInitalProps are bundled in the client package as the function is executed on the client when you transition a page. Photon is a native nodejs package and uses libraries that are provided by the node standard library like child_process which are not available in the DOM.

Segment from next js docs:

For the initial page load, getInitialProps will execute on the server only. getInitialProps will only be executed on the client when navigating to a different route via the next/link component or by using next/router.

This means the getInitalProps function is bundled and webpack can't resolve photon's deps as they are only present in node environment.

Next js is working on a new getServerProps which let you run database calls directly inside it but it is currently not stable. So please use the Next server routes till then as you have done with /api/graphql route.

[smakosh]

I tried getServerSideProps and it's not working actually

[guillaumeLamanda]

Thanks @pantharshit00 for this very clear answer. 👌

Indeed, we will need to use getServerProps but it is not stable for the moment.
I looking forward to using prisma/next.js combination. For data-fetching, SWR is a good candidate for a simple/clean workflow.

I guess this issue can be closed now.

[pantharshit00]

I tried getServerProps and it's not working actually
As @guillaumeLamanda it is not currently stable, we plan to write an example for it when it become stable.

Closing this now, please feel free to open a new issue if you feel this was not addressed properly

[kmturley]

I had a similar issue. It seems that a generic package import, traverses all files underneath regardless of whether the methods are actually called:

import { clientSideMethod } from 'mypackage'

Actually first goes to the root index.js inside the package and calls:

export * from './file'; // contains server-side code
export * from './utils'; // contains client-side code only

Therefore the error was triggered. Solutions are:

1. Use a more specific import import { clientSideMethod } from '../../node_modules/mypackage/dist/utils'
2. Dynamically import server-side modules when needed
3. Split packages or modules into client-side vs server-side

Very simple to fix, but frustrating to find the cause!