Winston: logger.debug is sent to stderr

[henhal]

Having added some debug and silly log prints, I was surprised to see my debug logs (using standard console transport) go to stderr, while all other log levels (except error, of course) go to stdout.

Is this intentional? I can't find any documentation about debug being sent to stderr by default?

[shinmyung0]

I also discovered this.. Not sure what the reasoning for this is?

[ikokostya]

I found answer in code comments https://github.com/winstonjs/winston/blob/b11cae2442153c35ecbd73a4af4937294c522bb1/lib/winston/transports/console.js#L49 (for backward compatibility)

You can setup debugStdout option of ConsolseTransport to true to get desired behavior.

[henhal]

Thanks @ikokostya, I guess this means that it is indeed intentional. I can't really see the rationale behind that decision though, but thanks for the workaround.

[indexzero]

Going to leave this open. The feature has existed for a long time, but if enough folks are not happy with it then we can remove it as a breaking change in [email protected]

[osher]

This is a gotcha that should not be the default, but a user deliberated choice.

I regret to say it's a gotcha of the kind for which whenever I'm invited for consulting - I have to recommend against winston, (if you ask - then in favor of pino for microservices, or bunyan for services that are willing to pay in performance in return for more sophisticated configuration).

Which is a pity. I usually prefer the older and more substantiated, and cannot do so with winston.

[osher]

@henhal - about the rational - I wrote my guess here:
https://github.com/winstonjs/winston/issues/927#issuecomment-344241400

[osher]

@indexzero - here are my two cents for you.

First cent:

What you have to keep in mind is the change in the industry that moves from monolyths to services, and onwards to microservices.

Docker has reinforced a change that has already started with pm2. Both of which capture the stdout/stderr of the process they support into files - and that makes the requirement to ask your process to manage files redundant and unecessary.

This in fact redefined the contract between Devs and Ops, changing the contact point from logs to stdio. Making console transport the default scenario.

The gain is that Devs can focus on Devs work - aka Business-Logic, and Ops can do Ops work - manage configurations, paths, log-rotation, log-centralization, and more. (the truth is - no matter how well Dev code is written - OS level log-rotation will work better and pose less risks to your BL process taking risks of file management away from your BL - leaving it more stable.

Second cent

You have to consider that when dev teams change paradigm (as in mono vs micro-svc) - they often change tools too. If winston behaves by default like old-world tools - they wont come to complain about it here - they will just leave it for tools that are better engineered to their new paradigm (e.g pino). They'll just say - yea, winston was cool with all the powerful plugins and stuff, but we don't need all that any more because all this work wasn't dev work in the first place, and ops can now handle it better.

In summary - Look, wisnton is a veteran substantiated logger. It won great popularity by addressing developers. But the young developers that started with winston mature and target a different topography.
Thus if winston wont adopt and mature it's priorities as well - it will sadly lose the lead 😞

[indexzero]

That's fair – but I think the capability mismatch more subtle. Based on the scenarios winston shines in it boils down to the difference between a "console" (i.e. stdout in a production process) and a terminal (i.e. a TTY enabled terminal).

In a terminal it is useful to separate these streams, but in a console (as you mentioned) it is not. Perhaps shipping two Transports is the answer or simply flipping the defaults and then documenting how to get terminal like behavior from a single Console transport.

Since we're still in RC this is a valid breaking change for 3.0.0 – strongly considering it based on the ~40 or so 👍across the various duplicate issues.

[indexzero]

Fixed in #1332. Will be released in 3.0.0 next Tuesday.