Comments (4)
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 ofloglevel
ordebug
orbunyan
etc. For all libraries that supportanylogger
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.
Related Issues (14)
- TypeScript: Cannot find module 'diary' or its corresponding type declarations HOT 7
- feature request: diaries that inherit from other scopes HOT 3
- [Feature] Allow logging of arbitrary object without message HOT 7
- [Bug] Handle cases where localStorage is not available. HOT 3
- Support `deno`
- Separate setup from logging in benchmarks HOT 4
- `LogFnAsError` type missing from `src/index.d.ts` HOT 3
- Trying to access process.env HOT 2
- Add check to filter log level HOT 2
- Add in a json logger as an extra
- Build babel plugin to enhance context HOT 3
- [RFC] Always "log" just don't output HOT 1
- TypeScript: Cannot find module 'diary' or its corresponding type declarations HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from diary.