How to deal with webpack warning from unmaintained grandparent module?

[davidascher]

Can you reproduce the problem with latest npm?

yes.

Description

Requiring winston generates a warning due to some webpack-warning-deserving code that winston's dependency, colors has.

It's currently impossible AFAICT to tell eslint to ignore it.

I'm opening this bug here because it's impossible to e.g. disable the webpack warning exprContextCritical without ejecting, but using a very popular logging module shouldn't require ejecting.

Alternatively, can anyone suggest an alternative to winston?

Related issues:

• Root issue is in colors: safe mode behaves strangely when using with webpack Marak/colors.js#137
• Related issue in winston: Critical Dependencies: the request of a dependency is an expression winstonjs/winston#984

Expected behavior

Adding winston to a CRA project should not add warnings on each page load, or it should be possible to deal with a "misbehaving" grandparent.

Actual behavior

import log from "winston";
log.info('hi there')

yields:

Compiled with warnings.

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

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

You may use special comments to disable some warnings.
Use // eslint-disable-next-line to ignore the next line.
Use /* eslint-disable */ to ignore all warnings in a file.

Environment

1. npm ls react-scripts (if you haven’t ejected):

[email protected] /Users/da/src/webpack-warning
└── [email protected] 

2. node -v: v7.7.2
3. npm -v: 4.4.4

Then, specify:

1. Operating system: OSX 10.12.4
2. Browser and version: Chrome 56.0.2924.87

Reproducible Demo

See minimal repo at https://github.com/davidascher/webpack-warning/

[Timer]

I suggest forking colors, removing the dynamic require (or putting it behind a nodejs/webpack&browserify compatible escape hatch to make it web bundle friendly), and releasing a semver-major (2.0).
You can then submit a follow up PR to winston switching to the new module.

Unfortunately we're not going to add an escape hatch for this, so you will need to eject or live with the warning.
Our philosophy is to require no configuration and avoid introducing it where otherwise unnecessary. Adding an escape hatch to bundle improper web packages is one we're definitely not going to support (sorry!).

---

You can check out bunyan, too.

Let me know if we can help with anything else. :)

[gaearon]

Longer term we aim to solve it here: webpack/webpack#4263

[timse]

Not sure how you plan to fix it, but webpack/webpack#4381 was merged, once released you can use it to suppress those warnings.
Would be happy to do a PR but not sure how you plan and what you plan to ignore :)

[Timer]

Oo that looks promising @timse. Can you please open a new proposal issue for us to talk details? Thanks!

[shai32]

Longer term we aim to solve it here: webpack/webpack#4263

@gaearon now that the suppress warnings feature was added to webpack, do you plan to use it ?
maybe open this issue again?

[timse]

ill reopen an issue :)

[shai32]

Can you add a link to the new issue?

[Timer]

It's linked above your comment, #1947.