Consider anylogger support? about diary HOT 4 CLOSED

Firstly, no! Thank you for taking notice!

I guess I'll need to understand what anylogger is—perhaps you can help me understand this firstly.

But on the outset, sure! I'm sure we can work something out.

from diary.

It's a logging facade. But I guess that's a bit cryptic 😅
If you know the Java ecosystem, anylogger is like slf4j. It's point is to be able to replace the logger a library is using and swap in another, without hassle. So it's not a logger, but a facade object that looks like a logger to client code and that is backed by any logger the app developer chooses. In most cases, through an adapter.

The problem it solves

When you npm install --save express for example, you get debug with it. Express uses debug for logging. When you npm install --save apollo-server-core you get loglevel. Because Apollo uses loglevel. When you npm install --save restify, you get bunyan. Because restify uses bunyan... If you somehow use all these libraries / frameworks in your app, you will end up with 3 loggers, but you had no say in this. The libraries made these choices for you. I think that maybe, you would have preferred for all these frameworks to use Diary instead right? Just as I prefer them to use ulog when I build an app with these frameworks. But unfortunately for us, it's not so easy to change. These libraries already made the decision for us! They coupled their code to their logger framework of choice and by doing that, we get these frameworks pushed into our project whenever we use these libraries. Anylogger tries to give the choice back to the application developer.

How it solves it

There are two ways we can use anylogger to make libraries and frameworks use the logger we choose instead of having them making the choice for us:

• Libraries and frameworks can use anylogger instead of loglevel or debug or bunyan etc. For all libraries that support anylogger in this way, we can easily make them use the logger we choose, by installing the anylogger adapter for the logger we choose and importing it in the entry point of our app.
• For libraries that don't support anylogger, like Express in the example above, we can fool them by aliassing the library we want to replace with a reverse adapter and then they will end up logging via anylogger without even knowing it.

The first part, where libraries actively support anylogger, is simplest for everyone. The library just picks anylogger as their logger instead of any specific real logger and then the app developer can install the right anylogger adapter for the logger he wants to use and include that adapter in his entry point. From there on the library will automatically use the selected logger.

The second part is a bit harder. It involves building a reverse adapter, which basically is an object or function that looks like the logger that the library or framework is expecting but that actually logs to anylogger. We then alias the logger we want to replace with that reverse adapter in our build and then use the same method as for the first part to choose the logger we actually want to use.

Example

Because debug is so simple, and anylogger's API is compatible with it, you can already easily make Express use for example loglevel instead of debug by doing this:

npm install --save express anylogger loglevel anylogger-loglevel

webpack.config.js

{
    resolve: {
        alias: {
            'debug': 'anylogger'
        }
    }
}

index.js

require 'anylogger-loglevel' // select loglevel as logger
var app = require 'express' 
// express will attempt to require debug, but because of our alias, 
// Webpack will give it anylogger instead. And because we installed the 
// anylogger-loglevel adapter, anylogger will actually log to loglevel. 
// So from this point on, all express logging will happen via loglevel

Progress

So far I have written adapters for Debug, Loglevel, Log4jS and started on Pino but is not finished yet. I'd love to add an adapter to support Diary and that's what this issue is about.

Furthermore, I'd like to eventually write reverse adapters so that you can also make Apollo and Restify use anylogger instead of loglevel and bunyan, so you can choose their logger as well. Debug needs no reverse adapter because it's so simple. But the reverse adapter for logleven should also be pretty easy. Bunyan, not so sure yet...

Relation to ulog

Just like libraries can choose to support anylogger to make switching loggers easy for their users, so loggers can choose to add native support for anylogger. This makes it even easier for users, because in that case they don't need to install an adapter. ulog has chosen this path to add native support for anylogger. That means ulog actually calls require 'anylogger' and then later exports anylogger as ulog. It overrides the ext method on the anylogger function to intercept the calls and return an ulog logger whenever a logger is created. In the docs for ulog I actually tell them to import anylogger instead of import ulog so that they can later switch to another logger very easy. And because ulog has native support they don't need an adapter.

Relation to Diary

I would like to enable all anylogger users to choose Diary as their logger. The least intrusive way to do this is with an adapter. For that purpose I made the project anylogger-diary. A step further would be for Diary to add native support for anylogger like ulog has. In that case, no adapter would be needed, because the adapter would be part of Diary itself. But I think maybe that's too much for you? It would mean that Diary would get a dependency on anylogger. With an adapter, Diary itself doesn't have to change at all. I can probably write this adapter, but it would be cool if you could help in the maintenance of it. Because you know when you are making (breaking) changes to Diary that might impact the adapter.

from diary.

Thank you for that explanation @Download I mean that makes perfect sense. The rust world also has this concept, partly the motive behind some of the api design of this library.

However I don't think it's well suited to make anylogger a dependency of this library. But am more than happy to assist in anyway around the idea of anylogger-diary. So what we must do next, and why?

from diary.

Got a new job and swamped with work, so basically didn;t do anything for over a month now. 🙄

You don't have to do anything of course :)
But if you feel like a challenge, you could have a quick look at anylogger-loglevel. It's an adapter for loglevel. I basically want to write a similar adapter for Diary. I will get to it one day but you could help make that happen sooner if you feel like it.

from diary.