Skip to content
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

Open
ef4 opened this issue Jul 5, 2019 · 4 comments
Open

Assist with node polyfilling #228

ef4 opened this issue Jul 5, 2019 · 4 comments

Comments

@ef4
Copy link
Collaborator

ef4 commented Jul 5, 2019

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:

Error: you tried to auto-import "some-library", but it depends on node's "path" library and doesn't work in web browsers. You could solve this problem by running the command:

    ember auto-import-polyfill path

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:

try {
  require('path');
} catch(err) {
  // not running in node, so leave out a few node-only features
}

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.

@ef4
Copy link
Collaborator Author

ef4 commented Jul 6, 2019

@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.

@ef4
Copy link
Collaborator Author

ef4 commented Jul 12, 2019

Some anecdata says that global is a pretty common one, and it's one of the safest and cheapest to automatically polyfill.

@ghost
Copy link

ghost commented Jul 22, 2019

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.
That library uses http and https.

@ef4
Copy link
Collaborator Author

ef4 commented Oct 15, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant