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

Include Node polyfill config #8

Open
ggetz opened this issue Jun 8, 2018 · 3 comments
Open

Include Node polyfill config #8

ggetz opened this issue Jun 8, 2018 · 3 comments

Comments

@ggetz
Copy link
Contributor

ggetz commented Jun 8, 2018

CC CesiumGS/cesium#6670

webpack build includes polyfills for several node.js libraries – over 100kb minified which isn't left out of the browser build.

Can be configured: https://webpack.js.org/configuration/node/

@puckey
Copy link

puckey commented Jun 9, 2018

PR here: #9

@thw0rted
Copy link

The problem with this solution is that if you don't turn off Node polyfills completely, it can mess up other libraries' feature detection, if it's e.g. looking for a global called process to determine if it's in a Node environment -- Angular does this.

Since the loadWithHttpRequest function is only needed at all outside of a browser environment, is there some way to exclude it from Webpack compilation completely when targeting the browser? I tried something that I thought might get removed by static analysis (const loadWithHttpRequest = "process" in window ? {body of current function} : function(){}) but Webpack still goes looking for the 3 libraries mentioned in the linked issue. I think the body could be removed by comment-based preprocessor directives, same as used today for removing sanity checks from performance-sensitive sections of a production build, but that would add complexity to the build toolchain that I'd just as soon avoid.

@thw0rted
Copy link

Update: I spent a little more time than I meant to chasing this down. I really wanted to tell Webpack to ignore the require("http") call, or resolve it with an empty / no-op module, or something, but for some reason I couldn't get it to respect resolve.alias. At any rate, I think just setting node.process = false fixes Angular's environment detection without stepping on the fix in Puckey's PR. As usual, the hardest part of this whole process was just understanding what Webpack is doing in the first place. That said, it would be neat to find an easy way of saying "if Webpack target is (not) X, completely ignore this code".

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

3 participants