Remove some obvious pitfalls. Migrate to winston@3 API

[indexzero]

The changes include:

• Remove usage of the default logger. TL;DR? Do not use the default logger if you have hard performance needs (like benchmarking).
• Use a stream Transport to be more closely aligned with feature set offered by peer sets.
• Begin to move to winston@3 API (notice the level property as a hard requirement for .log)

[mcollina]

Can you update the package.json so that I can install winston@3?
What do the benchmarks look like?

I'm very very happy about this PR, thanks @indexzero!

[jsumners]

You say "never use the default logger if you have hard performance needs (like benchmarking)." But Winston's readme does not make this clear, even on the 3.x branch. It merely says "If you would prefer to manage the object lifetime of loggers you are free to instantiate them yourself." That doesn't give the reader any indication that there is a significant performance difference between manual management and using the default logger. Therefore, I assume the way Winston gets used the majority of the time is via the simpler method: the default logger. Am I wrong?

I bring this up because I think our comparison benchmarks should at least include the patterns most generally used by the other loggers. It is certainly desirable to show comparisons against the other loggers's performance configurations as well; indeed, our benchmarks include Pino's "slow" default and fast opt-in mode.

[davidmarkclements]

let's benchmark both

[indexzero]

This is good to merge since [email protected] has been released to the world.

@jsumners the default API should considered deprecated as of [email protected]. Will be making that clear in the README.md of winston and removing it in winston@4.

Therefore, I assume the way Winston gets used the majority of the time is via the simpler method: the default logger. Am I wrong?

Also: yes, this is incorrect. Most issues / samples I've seen have new winston.Logger in them.

[jsumners]

Very nice work on speeding up Winston; those are some impressive gains.

I think we should wait to merge until 3.0.0 is out of release candidate stage.

[mcollina]

I'm ok with waiting, I think @indexzero has plans to move it to out of rc in the next week or so, I hope we don't wait too long.

[jsumners]

What should we do with this PR?

[indexzero]

I would suggest merging it. We're on [email protected] now (soon to be 3.0.0-rc4) – we're getting close to a final release, but there have been no material API changes.

(EDIT @indexzero): in rc 3.0.0 has gotten a good percentage of the userbase – the vast majority of new issues are about 3.0.0-rc*.

[jsumners]

Okay. Please remember to give us a drive-by commit to bump the version when you go final.

[indexzero]

@jsumners will do! Thanks for maintaining these benchmarks as part of pino.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.