Hey folks!
First off, some links:
oddlog - repository:
https://gitlab.com/frissdiegurke/oddlog
oddlog-cli - repository:
https://gitlab.com/frissdiegurke/oddlog-cli
I've been working on a project called oddlog, object driven data logging, lately. It's still in early development (as of now version 0.1.3, first code written about two weeks ago), but I'd like to present it to you anyways.
If you know a logging library called bunyan, oddlog will probably look pretty familiar to you. It's because bunyan has been the main inspiration, but also the reason why I needed to come up with a new project.
If you know bunyan:
At first I tried to get bunyan working the way I wanted it to
Have several output streams for the same messages - yes, bunyan is pretty good at this (even so the overuse of the name "stream" is pretty confusing)
Have some backtrack-logging as soon as a messages level exceeds a specified threshold - I ended up with a half-working solution for bunyan that had to wrap and use some of bunyans internal functions; an ugly hack
Have a reliable logging system - bunyan has a commented-out function called Logger#close which never got finished or even close to working. Thus when your application breaks or you call process.exit, you have no way to ensure the logging messages have been flushed to the files
Have good code quality.
Perform well
After taking a deeper look into the source-code of bunyan I decided not to fork and modify it but to create a very own logging library from scratch that provides similar functionality but better maintainability and more abstract transports.
As of today, I've managed to implement the basic logging system with most features bunyan provides, but in addition the possibility of nested transports (e.g. the backtracking transport allows you to specify sub-transports to deliver messages to) and advanced options for deferred transports (e.g. the backtracking transport). Since the backtracking transport does not deliver messages as soon they arrive, we have the question how to handle payload in the mean time. A deep clone would be optimal to prevent future modification by the user, but performs very bad. Thus I decided to give the control to the user application via some immediate* options for such transports.
In my opinion the maintainability is great and code quality pretty good (including jsdoc for relevant parts) - The same does not hold for the command-line interface yet; I'll have to tidy that up soon.
Performance wise I haven't completed all necessary benchmarks yet, but overall it looks pretty promising and outperforms bunyan in most tests.
If you don't know bunyan:
I'm not going to repeat, what I've already written within the project overview 😉 Just check it out.
Now to the purpose of this post...
As the project is growing more mature every day I'm in need of some real-world applications using it to detect any bugs and get some feedback about the experience. So if you're developing a non-professional node.js project that is in its early stages, so it's not too bad if something with the logging system goes wrong, it would be great if you could help me simply by using oddlog. I will definitely use it in all of my future projects since I'm confident it's better than all other logging libraries I know of. But of course it needs some proper testing and application yet. If you would use it while I'm improving it (and hence not working on applications that actually use it), it would probably get more stable faster.
However, keep in mind that it's in early development and may show up a bunch of bugs. Although my simple-by-design example applications work well.
Besides the default oddlog and oddlog-cli packages (written in ES6, but CommonJS module system), there are babel transpiled versions oddlog-legacy and oddlog-cli-legacy available for non-bleeding-edge versions of node.js - I'm not sure how they perform thought.
Feel free to contribute in any way, that would be highly appreciated 👍
Please share any comments and thoughts ❤
Many thanks, frissdiegurke
