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
Warning: Critical dependencies. #196
Comments
added better warning message |
Ah, so its a warning that one of the dependencies is an expression. Thanks Sokra! I would suggest that calling it a "critical dependency" doesn't quite describe what it is. Critical dependency makes me think of a dependency that must exist for things to work. Instead, this is simply warning about a dependency written as an expression. I would leave out the words "Critical dependency" and just let "the request of a dependency is an expression" describe it. Its much more understandable now tho. |
Would there be a way to suppress this warning for 3rd party libraries? I don't want to get this every time I build just because I have a dependency that does this. |
+1 on suppressing |
This error should not be ignored. It usually means that every file below a certain path will be included into the bundle (which should certainly not be ignored). It always needs to be resolved with aliasing or require contexts |
Can I then suggest the error points to these two links? On Wednesday, January 28, 2015, Johannes Ewald notifications@github.com
Mark Nijhof |
The error message is confusing, yes @sokra. Unfortunately these problems can not be solved all the same way. It heavily depends on what the library author is trying to achieve, but almost always it can be avoided at all. See #733 and ansman/validate.js#12 (comment) |
But I have no direct influence in how a third party lib does things. Can On Wednesday, January 28, 2015, Johannes Ewald notifications@github.com
Mark Nijhof |
@MarkNijhof, I believe that's what @jhnns is saying. Using aliases, require contexts, or some other mechanism, there is a way to fix the issue. webpack is powerful. |
Ah misunderstood, and yes very happy with webpack On Wednesday, January 28, 2015, Kent C. Dodds notifications@github.com
Mark Nijhof |
Try the ContextReplacmentPlugin... |
Thanks will try tomorrow :-) On Wednesday, January 28, 2015, Tobias Koppers notifications@github.com
Mark Nijhof |
I had the same warning using: let Class = require(url); and the warning disappeared when I did the following: let Class = require(`${url}`); Should I worry about this thing? Thanks! |
@ayozebarrera that's strange, because your Please be aware of that ES2015 modules won't allow dynamic imports, so there's no upgrade path for your code. |
Yeah it's strange because I have dynamic imports in two different places of my code. But the warning only appeared in this last. So checking the other dynamic import I noticed that the difference is the string... and i.e., there's no warnings from webpack ^^ Thanks for the help, and hope my feedback help you to catch any bug! |
ES6 modules don't allow dynamic imports? Isn't that a huge problem in cases of circular dependencies? |
Nope. Dynamic imports and circular dependencies are unrelated. ES2015 is able to handle circular dependencies. |
@jhnns I take back what I said, I was using dynamic requires to refer to something else. My bad |
Hi, I just got this error because a library I use does do this. Could you maybe add some explanation to the error message? It was not clear to me that "the request of a dependency is an expression" == "there is a dynamic import here and dynamic imports should not be used". |
Getting it with:
|
@mmahalwy The code you're using is too generic, webpack needs to include all files inside the current folder and all files in child folders. Try to make the path more explicit, like |
So one of the third party libraries I'm using (Tabletop) does this:
Does Webpack bundle anything extra as a result, or what should I do to tell Webpack to not make any attempts for this, etc, because this |
I've read the many comments on this issue and still can't work out how to get rid of the error. It's fine when it's your own code and you can use require contexts, but if it's in a third-party module that you don't control, then it's harder. In my case, bundling Mocha causes this error, but it still works fine because I don't use any of the functionality that's affected. So, I just want to suppress the warning. In case it helps anyone else, here's the best I could come up with. It's a dirty hack that looks for the path that mocha is trying to load from ( new webpack.ContextReplacementPlugin(
/^\.$/,
(context) => {
if (/\/node_modules\/mocha\/lib/.test(context.context)) {//ensure we're only doing this for modules we know about
context.regExp = /this_should_never_exist/
for (const d of context.dependencies) {
if (d.critical) d.critical = false;
}
}
}
) (add the above to |
…ings (https://typeorm.io/#/faq/how-to-use-webpack-for-the-backend) and expression-based imports because webpack doesnt like these (webpack/webpack#196)
…ings (https://typeorm.io/#/faq/how-to-use-webpack-for-the-backend) and expression-based imports because webpack doesnt like these (webpack/webpack#196)
…ings (https://typeorm.io/#/faq/how-to-use-webpack-for-the-backend) and expression-based imports because webpack doesnt like these (webpack/webpack#196)
…ings (https://typeorm.io/#/faq/how-to-use-webpack-for-the-backend) and expression-based imports because webpack doesnt like these (webpack/webpack#196)
…ings (https://typeorm.io/#/faq/how-to-use-webpack-for-the-backend) and expression-based imports because webpack doesnt like these (webpack/webpack#196)
Addresses issues #25 and #27. Previously, `require` was invoked dynamically, through the custom function `condRequire(module_name)`, but Webpack throws errors on dynamic `requires` (see webpack/webpack#196). This commit fixes that by removing `condRequire` and replacing it with explicit `require`s for each module.
I also have this with this library https://github.com/jeanlescure/short-unique-id i use it in another library and now this "warning" leaks into any consumer of my library, altough nothing seems to be wrong at all. I have to do something about it, does someone have an idea how to supress it for any consumer of my library? |
I wanted to share my own findings in investigating these warnings. In my experience, even though they can be suppressed (e.g. with |
Becuse Webpack is super annoying: webpack/webpack#196
What does this warning mean? Can this warning give a little more information as to its significance and what you might want to do about it (or perhaps where to find more information about it)?
The text was updated successfully, but these errors were encountered: