-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V5 add back support for node builtins #11764
Conversation
Investigating if webpack config of mainfields is the root cause of the issue https://webpack.js.org/configuration/resolve/#resolvemainfields |
Do you mind explaining how to solve the issue step by step for a beginner. I keep getting the same issue, but I am still very new to all of this. Thank you! |
Opened an issue in Webpack: webpack/webpack#15007 If a package like "handlebars" is imported, webpack fails to resolve import using the existing "browser" main field and fallsback to using the "main" field resolving the node js version of the package. This ends up asking for node js builtin packages - if we add support for builtin packages we could risk adding backend code in the browser. We might need to add documentation regarding this and some guidance for developers not experienced enough to realize the difference between npm packages |
@Rubenvet please use the issue tracker or stack overflow - this pull-request is for discussing a solution |
I see the intent of the Webpack resolve.fallback option a tool for package maintainers - not consumers of packages |
Suggestion for documentation / migration: #11756 (comment) |
I tried upgrading few of my projects to 5.0.0 but they all stopped working cause |
// Check app package.json for fallback dependency making sure we use project installed fallbacks | ||
try { | ||
// Use installed fallback | ||
fallbacks[nodeModule] = require.resolve(fallbackModule); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want to resolve it from the app you need to set the paths
to point to it, otherwise you're resolving it from react-scripts
itself which means you need to add them all as peer dependencies
| os | os-browserify/browse | | ||
| path | path-browserif | | ||
| punycode | punycode | | ||
| process | process/browse | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: should be process/browser
(missing r at the end).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least half the names in the 2nd column seem to be missing their last letter:
browserif
should bebrowserify
? (multiple variants)stream-htt
should bestream-http
?readable-stream/duple
should bereadable-stream/duplex
?
etc etc etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're looking at this at the moment, and just noticed this issue too. Thanks @no23reason and @PjotrB.
Is fixing this issue still on track for the milestone 5.0.1? |
- workaround cra@5 builtin module issue, temporarily use react-scripts@4 - workaround: facebook/create-react-app#11764
- workaround cra@5 builtin module issue, temporarily use react-scripts@4 - workaround: facebook/create-react-app#11764 - complete example code: https://docs.metamask.io/guide/ethereum-provider.html#using-the-provider
|
||
NodeJS builtin fallbacks enable you to import NodeJS builtin modules meant for Node and fallback to browser specific modules in your web application. | ||
|
||
Per default Create React App set fallbacks to empty modules in production build and development fallbacks in development mode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per default Create React App set fallbacks to empty modules in production build and development fallbacks in development mode. | |
This restores the previous behavior in Webpack < 5, where Create React App used to include these builtin fallbacks. |
I think this is how the sentence was intended, connecting to the previous sentence. I changed the inclusion to past tense.
Webpack v5 has wrecked my React applications, and I pretty much can't code. This is a disaster. I have tried adding fallbacks, installing the million dependencies, downgrading react-scripts to 4.0.3. This is an EMERGENCY and needs to be FIXED NOW as literally 0 solutions work. Speaking of work my BUSINESS IS SUFFERING. Again this needs to be fixed IMMEDIATELY. |
There are now approximately 7-8 vulnerabilities in the NVD in npms that are depended upon by React 4.x -- would love to move to React 5.x, but can't because of the problem this PR fixes. |
Careful, I think craco is only using react-scripts v4 |
@ryan-henness-trimble that is a valid concern but for this basic usage, craco has worked fine for me :) random add-on: I know also there are other ways to do it e.g. webpack recommends using "fallback" config field which might look like this, as an alternative to node-polyfill-plugin
xref https://viglucci.io/how-to-polyfill-buffer-with-webpack-5 |
In my opinion, polyfills are bad engineering design. |
@pavlovp yes, it should; but it doesn’t matter if it should or not - it has for a decade, and it shouldn’t be changed now. |
@cmdcolin Thanks for the craco config! For posterity, I had to add a webpack: {
configure: {
resolve: {
/**
* create-react-app 5 uses webpack 5, which no longer ships with node polyfills.
* We use these polyfills throughout the project either directly or via a dependency.
* If/when CRA allows us to add these back in (https://github.com/facebook/create-react-app/pull/11764),
* that would be preferrable to using craco.
* Craco's team is looking to give it up (https://github.com/gsoft-inc/craco/issues/415).
* Possible alternatives: react-app-rewired or ejecting from CRA
*/
fallback: {
assert: require.resolve("assert"),
buffer: require.resolve("buffer"),
process: require.resolve("process/browser"),
stream: require.resolve("stream-browserify"),
},
},
plugins: [
new webpack.ProvidePlugin({
Buffer: ["buffer", "Buffer"],
}),
],
},
}, |
For now, we solved this with const Webpack = require("webpack");
module.exports = function override(config) {
// Required polyfill packages
config.resolve.fallback = {
...config.resolve.fallback,
console: require.resolve("console-browserify"),
crypto: require.resolve("crypto-browserify"),
path: require.resolve("path-browserify"),
process: require.resolve("process/browser"),
stream: require.resolve("stream-browserify"),
util: require.resolve("util"),
};
// Required global polyfill
config.plugins = [
...config.plugins,
new Webpack.ProvidePlugin({
Buffer: ["buffer", "Buffer"],
process: "process/browser",
}),
];
return config;
}; |
Any update on this? |
For anyone searching for a solution to this in the meantime - here's a blog post (seems like from a company whose product was broken by this upgrade) outlining what seems to be the most common solution: https://alchemy.com/blog/how-to-polyfill-node-core-modules-in-webpack-5 |
This is an insane for such a small issue but there is no alternative for the time being. See facebook/create-react-app#11756 and related PR facebook/create-react-app#11764.
Would be great if anyone are up for taking over this pr, currently out of time 🙏 |
This is broken since last year, It should be the highest priority issue on the backlog. Does nobody on the core team has any time for fixing this issue? which is spoiling the whole developer experience of using CRA |
The problem we see here is an assumption if something is using npm so it is technically using node and that is should polyfill everything you can do in node. PLEASE NO. Just because everyone does it it does not mean its correct - a terrible reality in npm land.. Thank god Webpack dropped that! Overall the distinction between frontend and backend packages in the node ecosystem is bad (I would even say its horrific). But that does not mean in any world we should polyfill fs, crypto or other into webapps. This is a terrible idea, even considering the idea of polyfilling node builtins, because e.g. you DO NOT call crypto on your client. Its a historical problem that finally gets eradicated (slow but steady) - CRA used to include polyfills for node js stuff that shouldnt have been running in the browser including crypto. If you imported node crypto modules directly in your component that should not ever have because nodes crypto module IS NOT a browser module but what they did for us was to polyfill those things. Finally React realized that this is probably not a good idea and the team made the right decision with v5 to not longer do this because doing that is just bad. The vast majority of the things in node were built to run on the server because node is serverside javascript. There is actually a new W3C working group who argue about base set of javascript commands and functionality should exist on all platforms ( be it node, deno etc). So PLEASE DO not reintroduce back support for node builtins! Despite the title this video is a great must watch for everyone that demands this comes back to CRA!! Just watch the first 20 minutes.. |
@BearCooder while that's true that usage doesn't indicate correctness, this is actually the correct behavior. These are node modules, and a node module bundler should be providing these polyfills, or else it's broken. Webpack is who made the decision, to be clear, not the CRA team - they either went along with it or failed to correct it when updating - and it's caused an inordinate amount of cost and pain for developers since. https://medium.com/sindre-sorhus/webpack-5-headache-b6ac24973bf1 covers it well. WinterCG isn't relevant here except that it makes (according to your argument) is the opposite mistake - adding APIs designed exclusively for the browser to servers. If WinterCG makes sense, then polyfilling node core modules also makes sense - they're two sides of the same coin. (Additionally, the npm ecosystem is the largest, and imo also the best, out of every language, but that's just an offtopic discussion) |
CRA docs says we can use process.env to get access to ENV variables. That was true for v4. Not anymore for v5. |
[x-post from GitHub issue here] For those just finding this, as of November 18 2022, here is the solution that worked for me: Use react-app-rewired
Create config-overrides.js in the root with the following:
Change your build scripts in package.json
Replace dependencies with similar packages I had to do this twice, once for I ran:
That fixed the build errors I was getting! I can now |
Guys better prepare to switch over to something else than Create React App. |
Vite seems like the obvious choice |
Fixed #11756 by adding option to install nodeJS builtin fallbacks