Reorder logging levels to reduce debug noise #96
Comments
|
I agree, the documented order (btw it's documented twice in the README, the latter one makes more sense) is very unuseful. I would expect Anyway, I don't see the logLevel actually making any difference. Changing the logLevel to any of the documented levels, I still get messages of all levels in the output. |
|
Yeah, migrating to signale, I've immediately stumbled upon this! |
|
Any thoughts on this @klaussinani? I'm considering migration to a different logging library because of this limitation. |
|
I agree that this order make no sense and is very limiting when using this lib. I would add that the
|
|
Agreed; signale's ordering seems wrong. The log levels are listed here: https://github.com/klaussinani/signale/blob/master/src/signale.js#L90-L98 This is contrary to, for example, https://github.com/winstonjs/winston#logging-levels, which is apparently referring to an RFC. Regardless, Winston's ordering is more intuitive to me. semantic-release seems to workaround this by re-declaring the types to a simpler subset, and perhaps avoiding log levels altogether? (I haven't thoroughly read their code; maybe I'm wrong about this) IMO the best workaround is to subclass If we devise a nice preset, we can publish it as a library. |
|
I was in the middle of the refactoring from winston to this library when I hit this issue and had to rollback. |
|
@rafaelrpinto since you made it halfway through the refactor, did you try the subclassing solution I proposed? |
No as we avoid depending on workarounds as much as possible. But thanks for sharing your solution. |
|
That makes sense. They should add that mechanism to their official API so it's not a workaround. |
What's inside: 1. Added the "alert" logger, it is intended for messages that must be seen, for example, to manually catch an error. 2. The "debug" level now has a low priority and is not so visually highlighted: it is intended for unimportant messages that are usually not needed, but which would be useful to have in the system if something goes wrong. 3. In case someone wants to inherit from the "Signale" class, the "clone" method now correctly creates an instance of the current class with which it was created. 4. Added the ability to set your own log levels, without having to inherit to override the "_logLevels" getter. Fixes klaudiosinani#96
What's inside: 1. Added the "alert" logger, it is intended for messages that must be seen, for example, to manually catch an error. 2. The "debug" level now has a low priority and is not so visually highlighted: it is intended for unimportant messages that are usually not needed, but which would be useful to have in the system if something goes wrong. 3. In case someone wants to inherit from the "Signale" class, the "scope" method now correctly creates an instance of the current class with which it was created. 4. Added the ability to set your own log levels, without having to inherit to override the "_logLevels" getter. Fixes klaudiosinani#96
What's inside: 1. Added the "alert" logger, it is intended for messages that must be seen, for example, to manually catch an error. 2. The "debug" level now has a low priority and is not so visually highlighted: it is intended for unimportant messages that are usually not needed, but which would be useful to have in the system if something goes wrong. 3. In case someone wants to inherit from the "Signale" class, the "scope" method now correctly creates an instance of the current class with which it was created. 4. Added the ability to set your own log levels, without having to inherit to override the "_logLevels" getter. Fixes klaudiosinani#96
Is your feature request related to a problem? Please describe.
Currently I find it difficult to effectively reduce noise in my signale logging due to how the logging levels are set up.
Traditionally with logging libraries I've used, the
debuglevel would be higher in the chain thaninfo. This allows me to set logging level as info and ignore all debug information. From what I can see, this isn't possible in signale because setting log level to info will include debug (and setting to debug will exclude info).Describe the solution you'd like
Follow the conventional logging levels used by libraries such as winston (https://github.com/winstonjs/winston#logging-levels), with the priority order as follows:
Alternatively provide an array based API, allowing specific levels to be given (e.g.
{ logLevel: ['error', 'info', 'timer'] }). This would help avoid breaking changes but would be a slightly more complex solution.The text was updated successfully, but these errors were encountered: