winston: createLogger breaking changes under patch release

@DABH Sorry to commit code with some mistakes… 😭 @Pigotz Thanks for fixing it! 👍

@rossanmol Hmm, sorry but I can’t figure out what problem occurred. Do you face some concrete problems because of this change, or you wanna just mention this is breaking change? If you have some problem, can you explain it in detail?

In my environment, T extends Config.AbstractConfigSetLevels = DefaultLevels is enough and T extends Config.AbstractConfigSetLevels = DefaultLevels | Config.AbstractConfigSetLevels doesn’t make any difference. (because if you omit the generics, always DefaultLevels is set.)

Anyway, sorry to commit the breaking change in patch release. 🙇

@sigorilla , I’m waiting for the fixes/changes proposed by @AuHau @Mizumaki @rossanmol . Will give those folks a few hours – I will check back in a few hours and hopefully we can get a proper fix merged and released then. Thanks all.

Also, I believe that the methods that return another Logger instance should use the “parent’s” generic.

E.g. currently child is typed as child(options: Object): Logger. I would argue it should be child(options: Object): Logger<T>.

Here is a sample code, with the new problem (with the changes of #1817):

As you can see, DefaultLevels is too strict compared to what we had before.

However, there is another breaking change with this change where consumers could previously pass levels as Dictionary<number> or Record<string, number> but now are restricted by DefaultLevels.

Ahhhh, maybe I understand.

This is your problem. right ? If you type Logger directly, there is an error occurred.

Wait for me to fix it. really sorry