Consider dropping obsolete loggers

[kibertoad]

Bunyan wasn't updated for 3 years and can be considered dead.

On a somewhat more arguable note, new version of Winston wasn't published for a year, and there are known issues with handling heavy load, so I wonder if it should still be recommended.

pino, consola and log4js are probably the loggers to recommend in 2020.

I can provide a PR if approved.

[goldbergyoni]

@kibertoad Winston is still damn popular, isn't it? Any reputable benchmarks on its performance issues?

Which of the loggers that you mentioned qualifies according to our vendors recommendation guidelines?

https://github.com/goldbergyoni/nodebestpractices/blob/master/.operations/writing-guidelines.md

[kibertoad]

@goldbergyoni First of all, Winston no longer qualifies within original criteria, since last version published a year ago. Popular - yes, but it's the same story as it is with Express - it was there for a long period of time, so people use it out of habit, but it's something that has no observable benefits over newer alternatives, hence it is questionable whether it should be recommended officially.

https://github.com/pinojs/express-pino-logger#benchmarks

While it is created by pino folks themselves, considering that it is coming from NearForm folks, who have stellar reputation in Node.js community, and provide all the code necessary for reproduction, I would accept it at a face value, while Winston has winstonjs/winston#1364 for years.

Doesn't search in npm makes more sense for determining top vendors in Node.js case? And if we apply that criteria, then pino and loglevel are the ones that should be included.

[benjamingr]

I don't think Winston or Bunyan (or log4js) are terrible choices for logging and in certain cases they might work out nicely - but I don't think they have room in a "best practices" guide.

They are slow and unupdated but worse: they are unsafe - they encourage the use of persistence through an in-memory system. This means that if you have an uncaught exception your logger might miss it because the process goes down before the logger has a chance to persist the logs.

This means users miss the most important logs. In pino logs are written to stdout and are persisted through a separate process (see their docs). This solves the reliability problem.

[goldbergyoni]

Yo the all-mighty @benjamingr ! We have the right people with @kibertoad for this discussion.

I'm separating this into two discussions:

Vendors recommendation strategy

By now, the vendors guidelines helped us a lot since they rejected all niche package owners for adding themselves here. We don't want to confuse the audience and recommend up to 3 vendors. Some fundamental questions:

• Should we limit by npm downloads or GitHub stars?
• Should we limit by last edit time or last release time? For example, Winston updated their code recently but haven't released a new version for a year
• Shall we approach package owners before removing them and ask for a comment?

Loggers

I love Pino & the Pino team, it's my default logger. I'm playing the devil's advocate intentionally just to ensure we don't remove anyone for no good reason:

By now, I only see benchmarks that were created by the Pino team. I 100% believe them but It's not fair to base the performance discussion on this. Why do we suggest the Winston promotes non-stdout transports?

I'll also appreciate a tech clarification on why Winston might fail to stdout log before exiting - it write each entry immediately unlike Pino who buffers.

[kibertoad]

I can make an independent benchmark for modern loggers to provide some additional datapoints.

[benjamingr]

@goldbergyoni all streams are buffered (unless you explicitly opt out, you might remember from the C days) - even if you are writing to stdout, the buffering strategy is what matters.

Pino can be flushed though it rarely needs to. Winston just doesn't do streams correctly.

It encourages writing to a file in multiple places - but amongst others - the README.

I'd like to emphasize it's not a terrible or bad logger just like underscore isn't a terrible utility library and Q is not a terrible promise library - but as this is a best practices guide recommending something that is subpar because it popular seems antithematic.

[benjamingr]

As a side note stderr is not buffered (for obvious reasons since it's metadata and not output) and generally users should not log there

[goldbergyoni]

@benjamingr That's weird, I answered to this a while ago but seems like my comment was not posted.

Re-writing again - Given all the provided info, it resonates with me to put Pino on the top of logger list. I would include Winston as well due to its popularity but emphasize the performance differences and the value of logging to stdout

Makes sense?

[benjamingr]

Honestly? Not really:

I'd like to emphasize it's not a terrible or bad logger just like underscore isn't a terrible utility library and Q is not a terrible promise library - but as this is a best practices guide recommending something that is subpar because it popular seems antithematic.

[goldbergyoni]

I guess it also very much depend how we weigh factors like popularity and documentation. I fully agree with the advice to put Pino on top, I would include Winston for a while and see where it goes

[stale]

Hello there! 👋
This issue has gone silent. Eerily silent. ⏳
We currently close issues after 100 days of inactivity. It has been 90 days since the last update here.
If needed, you can keep it open by replying here.
Thanks for being a part of the Node.js Best Practices community! 💚