Reading your source code and capabilities of your logger made me realize what I expect and want from a logging library.
1. configurable log levels (convention is fine, but some apps require more fine grained control)
2. filterable log output - pino is doing really good here, you get JSON with level and message and can filter with jmes path. pretty printing is handled by another process that gets piped in the json lines (pino-pretty)
3. error handling logging - format and display errors with stack traces, maybe output 1-2 lines from the source code that caused it. That would be a game changer for nodejs applications.
4. Transports - easy way to hook into logging to fork off into another file, online service etc. Using a stream or EventEmitter.
**Other things to note:**
your logging class is stateful, I wouldn't want to set "no color" when another file is accessing the same logger. This should be an option when creating the logger or overwritable with the function (although I would prefer the first option)
It makes it even harder to manage that, when I can't create new logger instances on my own, as you just export `new Logger()` already. That means I can't use a prefix for different modules because `require('inklog')` will always give me the same logger instance.
Your methods are repeating the same logic over and over. Put them into a shared function.
Reading your source code and capabilities of your logger made me realize what I expect and want from a logging library. 1. configurable log levels (convention is fine, but some apps require more fine grained control) 2. filterable log output - pino is doing really good here, you get JSON with level and message and can filter with jmes path. pretty printing is handled by another process that gets piped in the json lines (pino-pretty) 3. error handling logging - format and display errors with stack traces, maybe output 1-2 lines from the source code that caused it. That would be a game changer for nodejs applications. 4. Transports - easy way to hook into logging to fork off into another file, online service etc. Using a stream or EventEmitter. **Other things to note:** your logging class is stateful, I wouldn't want to set "no color" when another file is accessing the same logger. This should be an option when creating the logger or overwritable with the function (although I would prefer the first option) It makes it even harder to manage that, when I can't create new logger instances on my own, as you just export `new Logger()` already. That means I can't use a prefix for different modules because `require('inklog')` will always give me the same logger instance. Your methods are repeating the same logic over and over. Put them into a shared function.