Warning during webpack compilation of ES6 modules #8401
Comments
|
Thanks for reporting this warning @bampakoa . Have you had a chance to look into whether this is a false alarm, or have any more information on the consequences of this warning? |
|
@OmarShehata I guess this has to do with tree shaking ES6 modules. That is if webpack can statically analyze something, then it can eliminate it during compilation if not used at all. Not sure though 🤔 |
|
@bampakoa I looked into this and I'm almost certain this it is a false warning from webpack. This code is checking to see if it is in a AMD requirejs environment and only executing code if that's the case. Webpack is attempting to analyze a code path that will never get executed (because we are not in such an environment) and then warning about it. A search of webpack's issue tracker seems to think this is a common issue (with webpack) I'm no webpack expert, but if there is a way we could annotate the Cesium code to let webpack know not to worry about the warning or file, we would be happy to add it. Anyone know? |
|
@mramato I see. After investigating this, I found that the only way to get rid of such warnings is using the ContextReplacement webpack plugin which is out of context as Cesium is concerned. So, I think that it is up to the consumer of the Cesium library to get rid of there errors. |
|
@bampakoa, have you figured out how to remove this warning with Also found another options for Webpack configuration to suppress these warnings: {
module: {
rules: { ... }
unknownContextCritical: false,
unknownContextRegExp: /^.\/.*$/
}
}It works but introduces another big and ugly warnings: $ yarn why sockjs-client
yarn why v1.21.1
[1/4] Why do we have the module "sockjs-client"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "[email protected]"
info Reasons this module exists
- "webpack-dev-server" depends on it
- Hoisted from "webpack-dev-server#sockjs-client"
info Disk size without dependencies: "1.21MB"
info Disk size with unique dependencies: "2.09MB"
info Disk size with transitive dependencies: "2.45MB"
info Number of shared dependencies: 10
Done in 0.49s.In comments to similar Webpack issue guys propose the same solution but, as I already told above, it doesn't work for me with Webpack 4. |
|
Respectfully, can I ask that this ticket be re-opened? I did a little digging into Webpack to figure out why this error was happening. I believe either of the two solutions above (using Webpack bundles libraries together. To do this efficiently and only include what is needed, it traces a dependency graph of the libraries that are The example that often pops up is: https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Core/GoogleEarthEnterpriseMetadata.js#L487 As I understand it, what these lines are doing is dynamically resolving the URL for the So to fix this for Webpack (and ruin it for the web) you could replace the first and third line with a This would allow Webpack to properly decide whether the dependent library needs to be loaded or not. I imagine you could use Pragmas to specify when to use the current code instead of a |
|
@ezze the latest version of the cesium-angular example contains a webpack configuration that eliminates the warnings mentioned. |
|
There are plenty of scenarios where a developer may not have ready access to the Webpack configuration (Angular, React CLIs to name a few common ones). I would also like to see this issue re-opened, because folks that want to use a common JavaScript framework have to find some way to work around default Webpack settings with Cesium. For React, I did find this Cesium workaround for React, which I will be evaluating: Thanks |
|
Seems that I had some luck to fix it today with ContextReplacementPlugin. Created a pull request in cesium-webpack-example. Just add the following to new webpack.ContextReplacementPlugin(/cesium\/Source\/Core/, ctx => {
// Suppress warnings "require function is used in a way in which dependencies cannot be statically extracted"
// in cesium/Source/Core/buildModuleUrl.js
const { resource, context, dependencies } = ctx;
if (resource === context) {
dependencies.forEach(dependency => dependency.critical = false);
}
return ctx;
}) |
|
@bluehaoran's comment is spot on. There is no reason why a Javascript library should reimplement modules in a proprietary way. The right approach is to fix the underlying issue and move everything over to There's currently only 33 matches for |
Vue 2.6.11package.json{
"name": "earth",
"version": "0.1.0",
"private": true,
"scripts": {
"serve": "vue-cli-service serve",
"build": "vue-cli-service build",
"test:unit": "vue-cli-service test:unit",
"lint": "vue-cli-service lint"
},
"dependencies": {
"cesium": "^1.72.0",
"core-js": "^3.6.5",
"vue": "^2.6.11",
"vue-router": "^3.2.0",
"vuex": "^3.4.0"
},
"devDependencies": {
"@vue/cli-plugin-babel": "~4.5.0",
"@vue/cli-plugin-eslint": "~4.5.0",
"@vue/cli-plugin-router": "~4.5.0",
"@vue/cli-plugin-unit-jest": "~4.5.0",
"@vue/cli-plugin-vuex": "~4.5.0",
"@vue/cli-service": "~4.5.0",
"@vue/eslint-config-prettier": "^6.0.0",
"@vue/test-utils": "^1.0.3",
"babel-eslint": "^10.1.0",
"copy-webpack-plugin": "^6.0.3",
"eslint": "^6.7.2",
"eslint-plugin-prettier": "^3.1.3",
"eslint-plugin-vue": "^6.2.2",
"node-sass": "^4.12.0",
"prettier": "^1.19.1",
"sass-loader": "^8.0.2",
"vue-template-compiler": "^2.6.11",
"webpack": "^4.44.1"
}
}vue.config.js// vue.config.js
const CopyWebpackPlugin = require("copy-webpack-plugin");
const webpack = require("webpack");
module.exports = {
pages: {
index: {
entry: "src/main.js",
template: "public/index.html",
filename: "index.html"
}
},
configureWebpack: {
plugins: [
// Copy Cesium Assets, Widgets, and Workers to a static directory
new CopyWebpackPlugin({
patterns: [
{ from: "node_modules/cesium/Build/Cesium/Workers", to: "Workers" },
{
from: "node_modules/cesium/Build/Cesium/ThirdParty",
to: "ThirdParty"
},
{ from: "node_modules/cesium/Build/Cesium/Assets", to: "Assets" },
{ from: "node_modules/cesium/Build/Cesium/Widgets", to: "Widgets" }
]
}),
new webpack.DefinePlugin({
// Define relative base path in cesium for loading assets
CESIUM_BASE_URL: JSON.stringify("")
})
],
module: {
// Removes these errors: "Critical dependency: require function is used in a way in which dependencies cannot be statically extracted"
// https://github.com/AnalyticalGraphicsInc/cesium-webpack-example/issues/6
unknownContextCritical: false,
unknownContextRegExp: /\/cesium\/cesium\/Source\/Core\/buildModuleUrl\.js/
}
}
}; |
|
I would also like to have this reopened, I update my app to work with build in typescript definition of Cesium, but this and the zlib problem mentioned in another ticket made me applied unwanted modification to webpack, just to fix some errors. |
|
I'm revisiting this now because of the comment I'm in the process of leaving on #8251 -- the short version is that the way Cesium deals with assets is not conducive to letting Webpack do smart static analysis. @bluehaoran explained this pretty well, but basically, Webpack is a bundler, and to do its job it has to understand your application's entire codebase -- all the JS it might ever use, but also any assets that are used by that JS (and perhaps assets that are used by those assets, etc). The ideal webpack build will produce a directory of files that can be statically served as-is, and all the files in your application that reference other files will have the correct path at runtime. There are several magic bits involved in this process. Webpack analyzes a bunch of different ways that code might reference other code or assets, then it tries to extract the location of the referenced asset(s), and include the asset in its pipeline so it will wind up in the build output. As that page explains, the simpler the reference, the better Webpack can narrow down exactly what it must include. So, As I commented on #8251, it looks like the way forward for Webpack to provide a reference to assets that must be dynamically loaded at runtime (via |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am using the version 1.63 - ES6 modules with an Angular CLI project.
When the Angular CLI builds the project, it emits the following warnings but the application works as expected:
Here is a snippet from my source code that depicts how I import Cesium into my application:
The text was updated successfully, but these errors were encountered: