Winston: Critical Dependencies: the request of a dependency is an expression

[rizqirizqi]

I got this warning while trying to build my app with webpack. The build was successful and it works as I expected. But, is there any problem with winston? If there is nothing to worry about, how to surpress the warning?

WARNING in ./~/winston/~/colors/lib/colors.js
Critical dependencies:
127:29-43 the request of a dependency is an expression
 @ ./~/winston/~/colors/lib/colors.js 127:29-43

WARNING in ./~/winston/~/colors/lib/extendStringPrototype.js
Critical dependencies:
106:31-45 the request of a dependency is an expression
 @ ./~/winston/~/colors/lib/extendStringPrototype.js 106:31-45

[vgrbr]

I have same issue after upgrade to webpack 2

[rizqirizqi]

UPDATE:
The warning is gone after I moved winston dependency from external package.json to internal package.json. So, I think it is not an issue in my project.

[davidascher]

The root cause is https://github.com/Marak/colors.js/issues/137.

[pratikgala]

@rizqirizqi can you provide more information on what you mean by moving your dependency from external package.json to internal.

[AndreColli]

I had the same issue using winston on electron.
That's how I solved it:

webpack.config.js

const { dependencies } = require('./package.json')

module.exports = {
    ...
    externals: [
        ...Object.keys(dependencies || {})
    ],
    ...
}

[LiranBri]

@AndreColli whats the rational behind your solution?

[AndreColli]

@LiranBri Treating winston as external library, he don't be bundled and he can reach their dependencies. If i understood correctly.
I got this from electron-vue code.
And here some explanation: https://jaketrent.com/post/howto-use-webpack-externals-property/

But this may be a specific solution for my case.

[LiranBri]

1. if winston won't get bundled, where would it get its code from?
2. why are you putting ALL the dependencies from package.json and not just winston?

[DABH]

I'm actively working on fixing the root issue for this now, see https://github.com/Marak/colors.js/issues/137 -- was just added to the repo, so I can help get this resolved properly. Stay tuned!

[DABH]

This should be fixed in colors@next / colors@>=1.2.0-rc0 -- opened #1209 !

[DABH]

^^that got merged in, so if anybody wants to confirm whether this issue is resolved using master, that would be great!

[davidm-public]

npm i colors@>=1.2.0-rc0 did not work for me
nor did npm i colors@next.

Issue resolved when i removed console-probe

WARNING in ./node_modules/colors/lib/colors.js
138:29-43 Critical dependency: the request of a dependency is an expression
 @ ./node_modules/colors/lib/colors.js
 @ ./node_modules/colors/safe.js
 @ ./node_modules/prettyjson/lib/prettyjson.js
 @ ./node_modules/console-probe/console-probe.js

[DABH]

Yeah, console-probe appears to implicitly depend on colors (through prettyjson -- https://github.com/rafeca/prettyjson/blob/master/package.json) -- so since the new colors version is not the default installed by prettyjson or whatever, you still end up with an old version of colors lurking somewhere in your node_modules (i.e., I don't think it's winston's fault). When the new version of colors is moved out of RC, you should be able to use console-probe fine again... so you could wait for that, or PR prettyjson to use colors@next, etc. FWIW the maintainers of colors are waiting for a couple weeks to move the RC to an official release (waiting for people to test, report any issues, etc.).

[indexzero]

Fixed via #1209. Released in 3.0.0-rc2

[shishiranshuman]

The above issue still appears in v3.0.1. Any suggestions would be greatly appreciated.

Warnings:

Version info:

Also, apologies if I have done some dumb mistake.

[DABH]

rm -rf node_modules and npm install again? That warning comes through logform... when you npm install, what version of logform do you get? Should be 1.3.0. Maybe you have a package-lock.json/yarn.lock/etc. that is keeping you from getting a newer version? Let me know!

[shishiranshuman]

@DABH Yes. You were right. Removing the yarn.lock file fixed that issue. But now it's showing me new errors while loading the files: The types declaration files and the LICENSE.

[DABH]

Could this be a webpack issue (for the LICENSE error -- very weird!)? e.g. https://github.com/webpack-contrib/extract-text-webpack-plugin/issues/104 Your bundler should not be requiring LICENSE as a module anywhere...

Could be due to dynamic requires in logform, which are avoided when using https://github.com/winstonjs/logform/blob/master/browser.js rather than https://github.com/winstonjs/logform/blob/master/index.js ; though winston presently just imports logform, not logform/browser.

As for the TS issue, no clues from that error message... any way you can provide more details, or a MWE we can play with?