v5 used to include polyfills for node.js core modules by default

[damozhang]

Describe the bug

Compiled with problems

Did you try recovering your dependencies?

yarn --version
1.22.15

Which terms did you search for in User Guide?

react-scripts 5 webpack Module not found: Error: Can't resolve 'fs'

Environment

npx create-react-app --info

Environment Info:

  current version of create-react-app: 5.0.0
  running from /Users/xxx/.config/yarn/global/node_modules/create-react-app

  System:
    OS: macOS 12.0.1
    CPU: (8) x64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
  Binaries:
    Node: 16.13.0 - /usr/local/Cellar/node@16/16.13.0/bin/node
    Yarn: 1.22.15 - /usr/local/bin/yarn
    npm: 8.1.0 - /usr/local/Cellar/node@16/16.13.0/bin/npm
  Browsers:
    Chrome: 96.0.4664.93
    Edge: Not Found
    Firefox: 94.0.1
    Safari: 15.1
  npmPackages:
    react:  17.0.2 
    react-dom:  17.0.2 
    react-scripts:  5.0.0 
  npmGlobalPackages:
    create-react-app: Not Found

Steps to reproduce

In a project with react-scripts v5.0.0

1. yarn add -D dotenv
2. yarn start

Expected behavior

Actual behavior

ERROR in ../../node_modules/dotenv/lib/main.js 24:11-24
Module not found: Error: Can't resolve 'fs' in '../node_modules/dotenv/lib'
 @ ./src/config.ts 5:0-28 8:0-13
 @ ./src/index.tsx 17:0-66 27:19-27 29:23-43 30:23-43 34:35-60

ERROR in ../../node_modules/dotenv/lib/main.js 26:13-28
Module not found: Error: Can't resolve 'path' in '../node_modules/dotenv/lib'

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
	- add a fallback 'resolve.fallback: { "path": require.resolve("path-browserify") }'
	- install 'path-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
	resolve.fallback: { "path": false }
 @ ./src/config.ts 5:0-28 8:0-13
 @ ./src/index.tsx 17:0-66 27:19-27 29:23-43 30:23-43 34:35-60

ERROR in ../../node_modules/dotenv/lib/main.js 28:11-24
Module not found: Error: Can't resolve 'os' in '../node_modules/dotenv/lib'

BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
	- add a fallback 'resolve.fallback: { "os": require.resolve("os-browserify/browser") }'
	- install 'os-browserify'
If you don't want to include a polyfill, you can use an empty module like this:
	resolve.fallback: { "os": false }
 @ ./src/config.ts 5:0-28 8:0-13
 @ ./src/index.tsx 17:0-66 27:19-27 29:23-43 30:23-43 34:35-60

3 errors have detailed information that is not shown.
Use 'stats.errorDetails: true' resp. '--stats-error-details' to show it.

Some useful comments:

• dependency aliases
• react-app-rewired config
• @craco/craco config
• hacking react-scripts with patch-package

[arjshiv]

I have the same issue as well

[FeiFanLiang]

me too

[raix]

Webpack 5 no longer shims node builtin packages. Its a breaking change.

[zfarhad]

I try to upgrade from v4.0.3 to 5.0.0 and It raise up the same error

Compiled with problems:

ERROR in ./src/App.js 1:40-111

Module not found: Error: You attempted to import /home/xxx/web/node_modules/react-refresh/runtime.js which falls outside of the project src/ directory. Relative imports outside of src/ are not supported.
You can either move it inside src/, or add a symlink to it from project's node_modules/.

[AdnanDervisevic]

Webpack 5 no longer shims node builtin packages. Its a breaking change.

Are we meant to eject for every app that relies on node builtin packages? Won't that be most production apps, since you will invariably import a node module that relies on this functionality

[raix]

My personal view:
I personally consider it bad practice to include code in the front-end that was ment for back-end usage.
From my experience:
I've seen developers of any experienced try adding back-end npm packages on the front-end.

In Npm there is no clear difference to help out developers, it's "Node Packages" not "Browser Packages"

Package maintainers should ideally build node or browser specific bundles.

Again this is my personal view I support the move in Webpack, I'll of course bring it up in the maintainer group.

(Also see the release notes regarding webpack 5 - there's a note regarding this breaking change for further details)

For now it would be helpful to collect examples of front-end packages suffering from this issue.
(The examples would help us reevaluate the decision)

[sean-daley]

Our two main usages are:

1. zlib
2. crypto

Our back-end compresses some of its data to optimize storage as well as network transfer. Our UI then uses zlib to uncompress it.
Our UI can also login using OAuth and it uses the crypto randomBytes and createHash methods to generate data for that authorization

[dylantf]

Webpack has some output about providing a fallback resolution, what's the correct way to supply that since we don't have access to the actual webpack config?

[jrr]

To toss in another example, the v5 upgrade showed me that the libraries for AWS Cognito use url:

> yarn build
Creating an optimized production build...
Failed to compile.

Module not found: Error: Can't resolve 'url' in '/path/to/app/.yarn/cache/@aws-amplify-core-npm-4.3.10-e9277c22ab-77b7fe62d8.zip/node_modules/@aws-amplify/core/lib-esm'
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
This is no longer the case. Verify if you need this module and configure a polyfill for it.

If you want to include a polyfill, you need to:
	- add a fallback 'resolve.fallback: { "url": require.resolve("url/") }'
	- install 'url'
If you don't want to include a polyfill, you can use an empty module like this:
	resolve.fallback: { "url": false }
> 

If you were a direct user of webpack v4, upgrading to v5, you have a few options:

1. stay on v4
2. remove usage of polyfilled modules
3. add polyfills

If I were in this situation, I'd be taking option 3. But as I understand it, that's not available today with non-ejected CRA.

It'd be nice if Webpack 5 had a single switch to flip, to restore v4's polyfill behavior. Then CRA could expose just that one switch. But there isn't: Webpack's migration guidance is to manually add polyfills to your webpack config.

https://webpack.js.org/blog/2020-10-10-webpack-5-release/#automatic-nodejs-polyfills-removed

Here are the polyfills that were formerly provided by webpack (note that the project is deprecated): https://github.com/webpack/node-libs-browser

..so what should CRA do?

[raix]

I've added a pr to gather feedback #11764

[BiancaArtola]

Same issue here. is there some documentation that we can follow for doing this migration?

[LukeNotable]

I'm not sure it's entirely a polyfill issue. I'm getting the Can't resolve 'fs' due to Handlebars, which (IIRC) should have been prevented by its browser setting in package.json.

[raix]

@LukeNotable thanks, interesting finding - I'll convert #11764 to a draft for now - would be great if it's an issue in the webpack config not resolving main fields correctly ref config: https://webpack.js.org/configuration/resolve/#resolvemainfields - will try to replicate

[jasonleehodges]

@zfarhad I had the same issue. Found out it was because I had Storybook as a dependency and it was using Webpack 4. Upgrading Storybook to use their new alpha version that supports Webpack 5 fixed me. So I would say, make sure none of your dependencies are using a conflicting version of webpack.

[raix]

@LukeNotable when importing 'handlebars/runtime' webpack seem to resolve correctly but if importing 'handlebars' it resolves to 'lib/index.js'

'''
"browser": {
".": "./dist/cjs/handlebars.js",
"./runtime": "./dist/cjs/handlebars.runtime.js"
},
'''
I'll take a second look tomorrow, could be a config issue in CRA

[German919]

ERROR in Plugin "react" was conflicted between "package.json » eslint-config-react-app.
Estoy teniedo este error y no encuentro como solucionarlo..

[jordanwilking]

Fwiw, seeing this for a package trying to use assert and stream-browserify.

[raix]

Webpack 5 and CRA v5 don't add fallbacks for nodejs modules any more, it's a breaking change - dotenv should not be added in the browser code related issues closed in dotenv repo

Migration steps from v4 to v5:

A: Go to the Npm or Github readme for the package you are trying to use and see if the package is meant to run in the browser

• If no - Then remove the package and find an alternative package better suited

B: Search in the package Github issues for "browser" and include closed issues, please. Example for DotEnv repo

• If the maintainers multiple times state that the package is NOT meant for usage in the front-end and close the issues - Then remove the package and find an alternative package better suited

C: If the package should support the browser - then open an issue here in the CRA repo and we'll look into it - here to help!

An example: @LukeNotable raised an issue - we've confirmed that as an issue, debugged and opened an issue in the Webpack repository.
Please note a very important detail regarding the handlebars package:

1. It provides a main field "browser" and bundle files specific to the browser
2. import "handlebars/runtime" resolves in the browser code
3. import "handlebars" resolves NodeJS version... Adding fallbacks for nodejs builtins would hide this issue

We have opened an issue in Webpack webpack/webpack#15007

Sorry for the breaking change, but we are trying to keep you safe - we are considering better error message / documentation etc.

Kind regards Morten

[lanwin]

Uh my guess is that this means a lot people can not upgrade to v5 for a long time. In example our own deps report 50 errors cause nodes assert ist used in various deps.

[dylantf]

"Then remove the package and find an alternative package better suited" is a great strategy when you have an unlimited budget, but in many cases these packages work just fine in the browser with a polyfill, and sometimes packages in the JS ecosystem go unmaintained and there aren't any good alternatives. If Webpack 5 has an option to include the polyfills, but CRA does not, are we just expected to immediately eject upon upgrading to edit the webpack config, or just stay on CRA 4?

[raix]

We need to make sure that we are fixing the root cause and not the symptom - like with the handlebars example above e.g. There might be an issue in Webpack webpack/webpack#15007 - let's evaluate if that fixes most of the errors.

To repeat #11756 (comment) we a considering adding an escape hatch and document why not to use it #11764

Again - if you are using packages not meant for the browser - and the maintainers of those packages keep closing issues for browser support and state that the package is not meant for the browser, then it's likely a good idea to find another package that supports the browser.

For more details on what nodejs builtin modules are see the nodejs api docs

[brownieboy]

So instead of having Webpack polyfil these missing node code dependencies, just have NPM install the polyfils as the named packages directly. You can specify the versions too. Example:

"devDependencies": {
  "buffer": "npm:[email protected]",
  "crypto": "npm:[email protected]",
  "stream": "npm:[email protected]",
  "util": "npm:[email protected]",
}

Works for me, although I needed some extra ones for http, https and zlib:

"devDependencies": {
    "buffer": "npm:buffer@^6.0.3",
    "crypto": "npm:crypto-browserify@^3.12.0",
    "http": "npm:stream-http@^3.2.0",
    "https": "npm:https-browserify@^1.0.0",
    "stream": "npm:stream-browserify@^3.0.0",
    "util": "npm:util@^0.12.5",
    "zlib": "npm:browserify-zlib@^0.2.0"
}

Is the npm: syntax needed though? This appears to just specify that the package comes from npmjs, but it will do that anyway, right?

Update
Looks like that npm: syntax is needed. When I removed it and then ran yarn install, it threw an error. I didn't try with npm itself.

[haneenmahd]

I happened to face this issue while using jsonwebtoken for my react app.

[Neurothustra]

so CRA is effectively broken? And the dev team doesn't care?

[haneenmahd]

The cause of this issue is when you use a module that was meant for Node for the Browser. With Webpack 5, they stopped bundling backend modules for web. So, I think the only problem is that you're using a module that wasn't supported for web. I think in my case it was using jsonwebtoken which relied on the polyfill of std Node modules. I switch to using jose which supports the browser.

[ljharb]

@haneenmahd everything that with a working bundler that includes core module polyfills, supports the browser. webpack 5 simply decided to stop being a working node module bundler.

[baughmann]

Are your guys bosses living in a VR world already? How about you tell them to take off the goggles and fix this crap.

[alome007]

[ArinCantCode]

for react-native errors:

first install react-native-web

and add

'react-native': require.resolve('react-native-web')

to your config-overrides.js

[Dronom]

I have the same issue with react-dev-utils:
BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default. [0] This is no longer the case. Verify if you need this module and configure a polyfill for it. [0] [0] If you want to include a polyfill, you need to: [0] - add a fallback 'resolve.fallback: { "url": require.resolve("url/") }' [0] - install 'url' [0] If you don't want to include a polyfill, you can use an empty module like this: [0] resolve.fallback: { "url": false }

P.S. Adding the "url" directly to your own package.json will solve the problem.

[michaelmarziani]

I think the salient point for any who come across this thread is that the React.js team no longer recommends CRA in the updated React docs. Here are the recommended frameworks for new react projects:
https://react.dev/learn/start-a-new-react-project

Good luck!

[Ebrahim-Ramadan]

The issue is tied to the version of react-scripts you are using. v5 has an issue as it excludes support for some node features and polyfills that were available in lower versions.

Your quick fix is to take react scripts down to v4 until a fix for v5 is in place unless you are comfortable with: 1) ejecting your app; 2) adding the webpack config changes that are needed.

[Ebrahim-Ramadan]

https://web3auth.io/docs/troubleshooting/webpack-issues#react-create-react-app

that solved it, nothing further

[robothoustra]

https://web3auth.io/docs/troubleshooting/webpack-issues#react-create-react-app

that solved it, nothing further

Thanks Ebrahim ! After testing a lot of solutions, only this one wordked for me.

[sohamzycus]

https://web3auth.io/docs/troubleshooting/webpack-issues#react-create-react-app

that solved it, nothing further

Solved it for me. Thanks @Ebrahim-Ramadan

[hoiekim]

Found another solution for the issue for folks who didn't like any of the above including me.

For example for crypto,

1. Create a folder called crypto
2. Create package.json under crypto folder and configure like this:

   {
     "browser": "client.js",
     "main": "server.js",
     "types": "index.d.ts" // optional
   }
   

3. Create a file crypto/client.js

   // crypto/client.js
   module.exports = window.crypto
   

4. Create a file crypto/server.js (edited snippet according to @ljharb, thanks)

   // crypto/server.js
   module.exports = require("crypto").webcrypto
   

Now import crypto folder you just created. Hope it makes sense.

[ljharb]

@hoiekim those aren't the same APIs; you'd need require('crypto').webcrypto to make them the same.

[noraliucode]

https://web3auth.io/docs/troubleshooting/webpack-issues#react-create-react-app

that solved it, nothing further

Wow that solved the issue! Thanks a lot Ebrahim!

[blueforesticarus]

hahhahahahahahaha ITS STILL OPEN!

[zxcfer]

There is no immediate solution for this. A more dev friendly solution might be to provide an alternative version that does include the node packages, so we can avoid the complex "solutions" we have right now.

[keithgabryelski]

this is crazy. CRAZY. but I can see this team is much like the flowjs team -- release a product into opensource but don't give a damn how it affects the clients when you make a breaking change with no reasonable way for current users to backout.