Consider not writing to stderr or allowing opt-out

It’s a bit surprising to have a library write to stderr as a side effect of invoking it:

Browserslist: caniuse-lite is outdated. Please run next command yarn upgrade caniuse-lite browserslist

Perhaps browserlist could also accept a callback that it would yield warning messages to.

I definitely understand the reasoning behind these warnings, but tools using browserslist may have their own command line interfaces that would be disrupted by it writing to stderr. In this case it would be best to have the tool decide how to surface this feedback.

If it’s still absolutely necessary to write to stderr, perhaps a default implementation would do so, but if the library was invoked with an onWarn or similar, it would not.

[ai]

Released in 4.5.4

[wbinnssmith]

Thanks for the reply @ai. Our use case is pretty close to what I described: in @parcel-bundler we invoke @babel/preset-env which uses browserslist. We have a rich cli interface[1] implemented with @vadimdemedes/ink, which relies on control of stdio. We currently patch console.log to avoid browserlist from writing directly to stderr.

[1] https://github.com/parcel-bundler/parcel/blob/v2-work-so-far/packages/reporters/cli/src/CLIReporter.js#L13