14 thoughts on “Warning: Critical dependencies.

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

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

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

    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

  4. Can I then suggest the error points to these two links?

    On Wednesday, January 28, 2015, Johannes Ewald notifications@github.com
    wrote:

    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.

    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
    http://webpack.github.io/docs/configuration.html#resolve-alias or require
    contexts
    http://webpack.github.io/docs/configuration.html#automatically-created-contexts-defaults-module-xxxcontextxxx


    Reply to this email directly or view it on GitHub
    #196 (comment).

    Mark Nijhof
    t: @MarkNijhof https://twitter.com/MarkNijhof
    s: marknijhof

  5. But I have no direct influence in how a third party lib does things. Can
    this be solved without touching their code? Else a way to supres individual
    errors would be great

    On Wednesday, January 28, 2015, Johannes Ewald notifications@github.com
    wrote:

    The error message is confusing, yes @sokra https://github.com/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
    #733 and ansman/validate.js#12
    (comment)
    ansman/validate.js#12 (comment)


    Reply to this email directly or view it on GitHub
    #196 (comment).

    Mark Nijhof
    t: @MarkNijhof https://twitter.com/MarkNijhof
    s: marknijhof

  6. 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!

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

  8. Getting it with:

    const loadRouteAsync = path => (nextState, cb) => {
      return System.import(path).then(module => {
        console.log(module);
        cb(null, module)
      });
    };
    
  9. @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 System.import("pages/" + path). Webpack has to guess in advance what kind of module you’re trying to import by analyzing your source code. If your source code gives no clue, webpack makes all modules in this folder importable.

  10. Such an annoying warning. I solved this by using the following in webpack.config.js:

    stats: {
        warningsFilter: [/critical dependency:/i],
    }
  11. 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 (.) and then checks that it is indeed mocha that’s trying to load from it, and if so tells it to look for things using a regex that should never match anything.

    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 plugins in your webpack config)

Comments are closed.