search

CesiumGS / cesium-webpack-example

The minimal recommended setup for an application using Cesium with Webpack.
Apache License 2.0
247 stars 161 forks source link

Include Node polyfill config #8

Open ggetz opened 6 years ago

ggetz commented 6 years ago

CC https://github.com/AnalyticalGraphicsInc/cesium/issues/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 commented 6 years ago

PR here: https://github.com/AnalyticalGraphicsInc/cesium-webpack-example/pull/9

thw0rted commented 6 years ago

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 commented 6 years ago

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