Next build does not respect webpack root externals on build

[cdaringe]

Bug report

Describe the bug

next.js does not honor webpack root-style externals during build phase. For example:

// next.config.js
// consider adding a webpack externals entry as follows to next.js webpack configuration
{
  react: "root React" // now require("react") statements should use [global.]React
}

on npm run build (next build):

 $ yarn build
yarn run v1.22.4
$ next build
info  - Creating an optimized production build  
info  - Compiled successfully

> Build error occurred
ReferenceError: React is not defined
    at Object.cDcd (/Users/c0d01a5/node/next-root-externals-bork/next-root-externals-bork/.next/server/pages/_app.js:245:18)
    at __webpack_require__ (/Users/c0d01a5/node/next-root-externals-bork/next-root-externals-bork/.next/server/pages/_app.js:23:31)
...

To Reproduce

Reproduction is very easy.

• I have setup a create-next-app demonstration here: https://github.com/cdaringe/next-root-externals-bork.
• A diff to reproduce is found in this single commit: cdaringe/next-root-externals-bork@eb48dc6

As you can see, I:

• externalize react using root React into webpack
• consume react in index.js
• used SSR APIs

on build, the error is emitted.

In development, this all works great! I provide my resources in my custom server, and everything is peachy 🍑 . Build time only, does this become a problem.

Expected behavior

Allow me to use webpack root externalized resources on build. One could argue that next DOES respect my externals--it is trying to lookup React--however, the way the build is executed prevents me from exposing my externals to the build worker. Because the build happens in a worker, my global, root-style resources get dropped from the current node process.

One solve would be allow users to participate in the worker process. The solve would be to introduce a super thin file, such as next-worker.js. Everytime we create a worker now, we would instead go through this script first:

• all workers enter via next-worker.js
• setupArgs = [...next.config.js::onWorkerInit (optional array of userland scripts), "original-worker-target.js"]
• next-worker.js executes each script in setupArgs.

In this fashion, next still does all of it's normal jest-worker goodness, just allows userland to participate.

For example, right now, everytime we create a worker, we do:

{
   "workerPath:"/.../node_modules/next/dist/compiled/terser-webpack-plugin/worker.js"
}

this proposal would suggest instead:

{
  workerPath: "/.../node_modules/next/dist/compiled/next-worker.js",
  setupArgs: [...maybeUserScripts, "/.../node_modules/next/dist/compiled/terser-webpack-plugin/worker.js"]
}

just a slight schema change, with a proxied entry to allow user scripts in.

Why would anyone want to externalize something like this?

I have a CDN-hosted, isomorphic lib that loads resources onto the window & into node. This library has things like react, react-dom, and some other common libs that our application uses. For reasons beyond this PR, we do not want next.js to bundle these assets--we want to control such assets. We ideally want to use the same library that we use client-side on the server to provide strongly aligned resources--hence the usage of root externals!

Screenshots

n/a

System information

Next data (cat package.json | grep next | pbcopy):

{
    "next": "9.5.2",
}

From npx envinfo | pbcopy:

  System:
    OS: macOS 10.15.5
    CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
    Memory: 1.51 GB / 32.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 14.4.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Managers:
    Cargo: 1.42.0 - ~/.cargo/bin/cargo
    Homebrew: 2.4.9 - /usr/local/bin/brew
    Maven: 3.5.4 - /usr/local/bin/mvn
    pip2: 18.1 - /usr/local/bin/pip2
    pip3: 10.0.1 - /Library/Frameworks/Python.framework/Versions/3.7/bin/pip3
    RubyGems: 3.0.3 - /usr/bin/gem
  Utilities:
    Make: 3.81 - /usr/bin/make
    GCC: 4.2.1 - /usr/bin/gcc
    Git: 2.19.1 - /usr/local/bin/git
    Clang: 1103.0.32.62 - /usr/bin/clang
    FFmpeg: 4.3.1 - /usr/local/bin/ffmpeg
  Servers:
    Apache: 2.4.41 - /usr/sbin/apachectl
  Virtualization:
    Docker: 19.03.12 - /usr/local/bin/docker
    VirtualBox: 5.2.22 - /usr/local/bin/vboxmanage
  SDKs:
    iOS SDK:
      Platforms: iOS 13.6, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
    Android SDK:
      API Levels: 29
      Build Tools: 29.0.2
      System Images: android-29 | Google APIs Intel x86 Atom
  IDEs:
    Android Studio: 3.5 AI-191.8026.42.35.5977832
    Nano: 2.0.6 - /usr/bin/nano
    VSCode: 1.47.3 - /usr/local/bin/code
    Vim: 8.1 - /usr/bin/vim
    Xcode: 11.6/11E708 - /usr/bin/xcodebuild
  Languages:
    Bash: 3.2.57 - /bin/bash
    Go: 1.14.4 - /usr/local/bin/go
    Java: 1.8.0_192 - /usr/bin/javac
    Perl: 5.18.4 - /usr/bin/perl
    PHP: 7.3.11 - /usr/bin/php
    Python: 2.7.16 - /usr/bin/python
    Python3: 3.7.0 - /Library/Frameworks/Python.framework/Versions/3.7/bin/python3
    Ruby: 2.6.3 - /usr/bin/ruby
    Rust: 1.43.0 - /Users/c0d01a5/.cargo/bin/rustc
    Scala: 2.12.8 - /usr/local/bin/scalac
  Databases:
    PostgreSQL: 12.3 - /usr/local/bin/postgres
    SQLite: 3.28.0 - /usr/bin/sqlite3
  Browsers:
    Chrome: 84.0.4147.125
    Firefox: 77.0
    Safari: 13.1.1

Additional context

Add any other context about the problem here.