-
Notifications
You must be signed in to change notification settings - Fork 109
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
Assist with node polyfilling #228
Comments
@jenweber can you remind me again the list of apps you mentioned that hit node polyfilling problems? I'd like to get a sense for which exact features they need. Some are easier than others. |
Some anecdata says that |
I created an example application recreating this problem that uses eventsource. I observed this in our application and applied your suggestion in #224 to fix our build. |
Webpack 5 disables the automatic polyfills by default. So we don’t need to be the bad guys. Library authors are going to need to get better at this. |
We turned off webpack's "automagically polyfill all the node things", because it wasn't intentional and we got real reports of people ending up with surprisingly huge polyfills that they didn't want in their build.
But it seems the general state of NPM authoring standards for browser code is poor, and many apps really do need to polyfill node features. It would help users if we can offer better guidance here.
Since we transpile dependencies by default anyway, it wouldn't be very expensive to add a babel plugin that detects node features and offers a clear message:
The command would install any necessary libraries (in this case,
path-browserify
) and update the auto-import config to use them.However, the challenge here is that libraries that are actually trying to be portable might only be checking for node features and then happily switch into a browser mode when they don't exist:
In these cases it's bad to automatically polyfill because it's unnecessary and you lose out on the library author's own preferred way of running in the browser. And it's bad to warn or error, because it may be legitimate to ignore. In general, we can't tell which things are hard dependencies and which have fallbacks in the library itself.
The text was updated successfully, but these errors were encountered: