`getServerSideProps` does not work with Parse server due to `child_process`

Bug report

Describe the bug

After generating a new Next project, adding Parse, adding a small bit of code to see if the two play together nicely, and running next build, I get the following error:

$ next build
Creating an optimized production build

Failed to compile.

./node_modules/xmlhttprequest/lib/XMLHttpRequest.js
Module not found: Can't resolve 'child_process' in '/Users/devanb/Projects/parse-test/node_modules/xmlhttprequest/lib'


> Build error occurred
Error: > Build failed because of webpack errors
    at build (/Users/devanb/Projects/parse-test/node_modules/next/dist/build/index.js:13:913)
error Command failed with exit code 1.

I’m not sure exactly what the issue is other than child_process, unfortunately. In over my head a little 😅

To Reproduce

Full reproduction here: https://github.com/DevanB/next-parse-server

System information

• OS: macOS 10.15.4
• Browser: Safari 13.1
• Version of Next.js: 9.4.0
• Version of Node.js: 12.16.3

[kachkaev]

Same here with next@9.4.1:

> Using external babel configuration
> Location: "/path/to/project/babel.config.js"
Creating an optimized production build  

Failed to compile.

./node_modules/command-exists/lib/command-exists.js
Module not found: Can't resolve 'child_process' in '/path/to/project/node_modules/command-exists/lib'

This happened after I bumped Next from 9.4.0 to 9.4.1 and also updated a few other deps in one small open-source side project. Here is the commit: https://github.com/kachkaev/video-easter-eggs/commit/d535f5919f82c72d940cf9529804cda935f7ba65

Simply pinning next to next@9.4.0 in package.json has not helped, so going to investigate further.

UPD: Bumping next to 9.4.1-canary.9 does not help either 🤔

UPD2: Probably my issue is in the user land, i.e. in https://github.com/kachkaev/video-easter-eggs/commit/5e3ffaee371c850b73ff81c4774aab9c3784c42c 🤔 It’s a pretty large diff, but most of it is just moving files around. There are no ESLint and TypeScript problems both before and after.

UPD3: @DevanB I resolved the issue for my project 🎉 It had nothing to do with Next.js, purely user land. Roughly speaking, I had:

src/shared/something/types.ts ← just TS types
src/shared/something/doX.ts   ← function that works on the server and in the browser
src/shared/something/doY.ts   ← function that only works on the server, depends on execa
src/shared/something/index.ts ← re-exports everything from the above three files

Here is what I mistakenly did while refactoring src/ui/MyComponent.tsx:

- import { doX } from "../shared/something/doX"
- import { SomeType } from "../shared/something/types"
+ import { doX, SomeType } from "../shared/something"

My expectation was that Next.js would tree-shake the import and thus exclude doY while building the client bundle. This did not happen though, so webpack started processing doY → execa → child_process and failed.

Replacing one import statement back with two resolved the issue. Hope that my investigation helps others who face a similar puzzle too 🙂

[DevanB]

@kachkaev this makes sense now. Testing locally.

– Update –

This worked! Thanks so much @kachkaev. I understand what’s going on now 😃

I’m closing this report @Timer. Thanks for the help 😄