How to deal with webpack warning from unmaintained grandparent module?

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: https://github.com/Marak/colors.js/issues/137
• Related issue in winston: https://github.com/winstonjs/winston/issues/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):

webpack-warning@0.1.0 /Users/da/src/webpack-warning
└── react-scripts@0.9.5 

1. node -v: v7.7.2
2. 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/

[gaearon]

Longer term we aim to solve it here: https://github.com/webpack/webpack/issues/4263

[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. 😃