Feature request - Built-in universal logger

Feature request

Is your feature request related to a problem? Please describe.

Universal logging that is light and customisable isn’t an easy task.

I’m currently using @unly/utils-simple-logger, which relies on winston (~ 40kB).

There are a few limitations with this implementation:

• It’s huge, in comparison to the benefits it provides (it could be a <2kB lib)
• It doesn’t play well with stack traces, because it wraps console and “lies” about where calls are from
• It doesn’t respect the console.log API, and cannot be a drop-in replacement for console.log

It has come to my attention through an open issue that Winston was adding about ~60kB to all pages (404 > 344kB without it), and this is a huge difference.

I’m using a custom logger for the following reasons:

• There are logs I want to be stripped in production stage, because I don’t want them visible (neither in server side nor client side), sometimes it’s to avoid spam/noise, sometimes it’s to avoid leaking sensitive debug info

Describe the solution you’d like

I believe this could be made available as an external package for those who wish to use it.

What do you use for logging at Next?

Describe alternatives you’ve considered

I’ve spent a few hours looking around what alternatives I could use, but after studying about half a dozen of alternatives, I’ve come short to no viable solution. Either they aren’t universal, or too big, or lack features, aren’t maintained, etc.

The 2 most interesting alternatives I’ve found are:

• ulog (formerly picolog) - See issue with Next.js
  • https://github.com/Download/ulog#logging-levels is a great feature (basically what I implemented in https://github.com/UnlyEd/utils-simple-logger
  • https://github.com/Download/ulog#querystring-parameter-1 - Interesting feature allowing to start debugging part(s) of the app without having to restart the server
  • https://github.com/Download/ulog#using-ulog-as-a-replacement-for-debug - Meant to become debug friendly
• debug - Interesting, but lacks must-have features such as “Logging levels”

Overall, ulog looks great, but there are a few important issues and bad design decisions. (https://github.com/Download/ulog/issues/16)

[Download]

Hi guys, I’m the author of ulog.

I wrote ulog an eon ago to be tiny and powerful and work everywhere. And 1.x is pretty much succeeding at that. However I found that I had 2 problems with it:

• Even though I made ulog as small as I could get it, I still did not want to use it in libraries / frameworks as a dependency because I don’t want to tie consumers to my choice of logging library
• I wanted more features such as formatting, which made the previous point even worse. I certainly don’t want to tie consumers of a library I am making to my choice of big logging library

I came up with this solution:

anylogger

The logger for libraries

When we want to do logging from a library, we don’t want to force the choice of logging framework on the application developer. Instead, we want to use whatever logging framework the application developer selected. anylogger let’s you do just that.

The idea here is a logging facade. It’s like slf4j in the Java world. A facade with a generic interface that you back with the logging library of your choice.

Currently I am working to get the following working:

• anylogger facade to be used by client code
• anylogger-debug Adapter that makes code using anylogger log to debug.
• anylogger-loglevel Adapter that makes code using anylogger log to loglevel.
• anylogger-log4js Adapter that makes code using anylogger log to log4js.
• ulog v2 Logging library that simply depends on anylogger so we don’t even need an adapter

It’s work in progress… I’m doing it on my own atm… And I don’t always have time to work on it.

However I really do feel a logging facade is what the Javascript world needs so framework and library vendors can just support any logger easily.

[Manikanta-20]

or any logger management ui like graylog?