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

Warning: Critical dependencies. #196

Closed
fresheneesz opened this issue Mar 11, 2014 · 116 comments
Closed

Warning: Critical dependencies. #196

fresheneesz opened this issue Mar 11, 2014 · 116 comments

Comments

@fresheneesz
Copy link
Contributor

@fresheneesz fresheneesz commented Mar 11, 2014

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)?

@sokra sokra closed this in c3a242f Mar 11, 2014
sokra added a commit that referenced this issue Mar 11, 2014
allow to configure when an automatically created context is critical
better warning message in critical dependencies warning

fixes #196
fixes #198
@sokra
Copy link
Member

@sokra sokra commented Mar 11, 2014

added better warning message

@fresheneesz
Copy link
Contributor Author

@fresheneesz fresheneesz commented Mar 11, 2014

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.

@kentcdodds
Copy link
Member

@kentcdodds kentcdodds commented Jan 19, 2015

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.

@MarkNijhof
Copy link

@MarkNijhof MarkNijhof commented Jan 28, 2015

+1 on suppressing

@jhnns
Copy link
Member

@jhnns jhnns commented Jan 28, 2015

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

@MarkNijhof
Copy link

@MarkNijhof MarkNijhof commented Jan 28, 2015

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

@jhnns
Copy link
Member

@jhnns jhnns commented Jan 28, 2015

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)

@MarkNijhof
Copy link

@MarkNijhof MarkNijhof commented Jan 28, 2015

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

@kentcdodds
Copy link
Member

@kentcdodds kentcdodds commented Jan 28, 2015

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

@MarkNijhof
Copy link

@MarkNijhof MarkNijhof commented Jan 28, 2015

Ah misunderstood, and yes very happy with webpack

On Wednesday, January 28, 2015, Kent C. Dodds notifications@github.com
wrote:

@MarkNijhof https://github.com/MarkNijhof, I believe that's what @jhnns
https://github.com/jhnns is saying. Using aliases, require contexts, or
some other mechanism, there is a way to fix the issue. webpack is powerful.


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

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

@sokra
Copy link
Member

@sokra sokra commented Jan 28, 2015

Try the ContextReplacmentPlugin...

@MarkNijhof
Copy link

@MarkNijhof MarkNijhof commented Jan 28, 2015

Thanks will try tomorrow :-)

On Wednesday, January 28, 2015, Tobias Koppers notifications@github.com
wrote:

Try the ContextReplacmentPlugin...


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

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

@ayozebarrera
Copy link

@ayozebarrera ayozebarrera commented Jan 19, 2016

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!

@jhnns
Copy link
Member

@jhnns jhnns commented Jan 19, 2016

@ayozebarrera that's strange, because your require() statement stays dynamic. There should still be a warning.

Please be aware of that ES2015 modules won't allow dynamic imports, so there's no upgrade path for your code.

@ayozebarrera
Copy link

@ayozebarrera ayozebarrera commented Jan 19, 2016

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!

@fresheneesz
Copy link
Contributor Author

@fresheneesz fresheneesz commented Jan 19, 2016

ES6 modules don't allow dynamic imports? Isn't that a huge problem in cases of circular dependencies?

@jhnns
Copy link
Member

@jhnns jhnns commented Jan 20, 2016

Nope. Dynamic imports and circular dependencies are unrelated. ES2015 is able to handle circular dependencies.

@fresheneesz
Copy link
Contributor Author

@fresheneesz fresheneesz commented Jan 21, 2016

@jhnns I take back what I said, I was using dynamic requires to refer to something else. My bad

@brodo
Copy link

@brodo brodo commented Apr 22, 2016

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

@mmahalwy
Copy link

@mmahalwy mmahalwy commented May 26, 2016

Getting it with:

const loadRouteAsync = path => (nextState, cb) => {
  return System.import(path).then(module => {
    console.log(module);
    cb(null, module)
  });
};

@jhnns
Copy link
Member

@jhnns jhnns commented May 27, 2016

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

@seiyria
Copy link

@seiyria seiyria commented Jun 8, 2016

So one of the third party libraries I'm using (Tabletop) does this:

  if (typeof process !== 'undefined' && !process.browser) {
    inNodeJS = true;
    var request = require('request'.trim()); //prevents browserify from bundling the module
  }

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 require simply does not need to be resolved.

@Ancientshield
Copy link

@Ancientshield Ancientshield commented Apr 24, 2020

08:29:10 webpack.1 |                                      Asset       Size       Chunks                         Chunk Names
08:29:10 webpack.1 |     js/application-e6df12ccd2f6f43a2d3c.js   5.65 MiB  application  [emitted] [immutable]  application
08:29:10 webpack.1 | js/application-e6df12ccd2f6f43a2d3c.js.map   5.62 MiB  application  [emitted] [dev]        application
08:29:10 webpack.1 |       js/tagsinput-e4036152fa3328826ac2.js    427 KiB    tagsinput  [emitted] [immutable]  tagsinput
08:29:10 webpack.1 |   js/tagsinput-e4036152fa3328826ac2.js.map    481 KiB    tagsinput  [emitted] [dev]        tagsinput
08:29:10 webpack.1 |                              manifest.json  689 bytes               [emitted]
08:29:10 webpack.1 |
08:29:10 webpack.1 | WARNING in ./node_modules/express/lib/view.js 74:13-25
08:29:10 webpack.1 | Critical dependency: the request of a dependency is an expression
08:29:10 webpack.1 |     at CommonJsRequireContextDependency.getWarnings (/Users/rd/training/node_modules/webpack/lib/dependencies/ContextDependency.js:40:18)
08:29:10 webpack.1 |     at Compilation.reportDependencyErrorsAndWarnings (/Users/rd/training/node_modules/webpack/lib/Compilation.js:1454:24)
08:29:10 webpack.1 |     at /Users/rd/training/node_modules/webpack/lib/Compilation.js:1258:10
08:29:10 webpack.1 |     at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/rd/start_training/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:15:1)
08:29:10 webpack.1 |     at AsyncSeriesHook.lazyCompileHook (/Users/rd/training/node_modules/tapable/lib/Hook.js:154:20)
08:29:10 webpack.1 |     at Compilation.finish (/Users/rd/training/node_modules/webpack/lib/Compilation.js:1253:28)
08:29:10 webpack.1 |     at /Users/rd/training/node_modules/webpack/lib/Compiler.js:672:17
08:29:10 webpack.1 |     at _done (eval at create (/Users/rd/training/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:9:1)
08:29:10 webpack.1 |     at eval (eval at create (/Users/rd/training/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:20:22)
08:29:10 webpack.1 |     at /Users/rd/training/node_modules/webpack/lib/Compilation.js:1185:12
08:29:10 webpack.1 | ℹ 「wdm」: Compiled with warnings.

@smac89
Copy link

@smac89 smac89 commented Apr 27, 2020

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

stats: {
    warningsFilter: [/critical dependency:/i],
}

@ChrisSargent
Copy link

@ChrisSargent ChrisSargent commented May 18, 2020

I'm working on a lambda application with AWS amplify, hence my need for bundling (so I can't exclude Node Externals for example). I am seeing this error from a package (https://github.com/Nike-Inc/lambda-logger-node) which includes the following code:

function hasModuleLoaded(moduleName) {
  try {
    return !!require.cache[require.resolve(moduleName)]
  } catch (e) {
    if (/Cannot find module/.test(e.toString())) return false
    throw e
  }
}

Also, looking at another npm module, I can see the code does a similar thing which produces this error: https://github.com/kownacki/module-available/blob/master/index.js

"use strict";

module.exports = function(moduleName) {
    if (typeof moduleName !== "string") {
        throw new TypeError("Passed parameter must be a string.");
    }

    try {
        require.resolve(moduleName);
    }
    catch (error) {
        if (error.code === "MODULE_NOT_FOUND") {
            return false;
        }
        throw error;
    }
    return true;
};

It kind of seems a legitimate use case for this kind of requiring so I'm just wondering what the recommended way of handling this could be?

EDIT: Actually, I guess the issue in a 'bundled' app is that require.resolve will always return false. But still, I wonder how to therefore suppress the error using the ContextReplacementPlugin?

@tstibbs
Copy link

@tstibbs tstibbs commented Aug 28, 2020

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)

jjhbw added a commit to jjhbw/typeorm that referenced this issue Sep 17, 2020
jjhbw added a commit to jjhbw/typeorm that referenced this issue Sep 28, 2020
jjhbw added a commit to jjhbw/typeorm that referenced this issue Oct 5, 2020
jjhbw added a commit to jjhbw/typeorm that referenced this issue Nov 18, 2020
jjhbw added a commit to jjhbw/typeorm that referenced this issue Nov 18, 2020
jsvine added a commit to jsvine/notebookjs that referenced this issue Jan 30, 2021
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.
@macrozone
Copy link

@macrozone macrozone commented Feb 10, 2021

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?

@johndiiorio
Copy link

@johndiiorio johndiiorio commented Jul 30, 2021

I wanted to share my own findings in investigating these warnings. In my experience, even though they can be suppressed (e.g. with exprContextCritical: false or by tricking webpack with template literal strings), they are usually indicative of some real issue and should be addressed, especially if they appear suddenly. If you are doing things on the backend, try using webpack-node-externals to not bundle your node_modules. In my case, I switched to a monorepo setup (e.g. Lerna / Yarn workspaces / NPM workspaces) and was using webpack-node-externals, but ran into this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet