I am trying to decide on what logging module to try out for my next project. I'd love the dev community's input on:
A) What logging lib you use
B) Whether you structure your logs (and how)
C) Where you store your logs or any other logging infra you have
I have been using Winston, but I would like something that supports structured logging out of the box. The general ecosystem on NPM seems to be pretty split, and some options seem to be popular but un-maintained.
Latest comments (38)
I'm the author of LogLayer. Unlike the other loggers out there, LogLayer separates object injection from the log message itself via a fluid API. It provides structured logging and has transports for writing logs to files with rotation, cloud providers, and other logging libraries as well.
I recently wrote and released a new library for logging in JavaScript that was created from the ground up with TypeScript and works seamlessly in the browser and node environments. It also offers a ton of other features (like log listeners for capturing log data) and it fully wraps the entire Console API standard. It offers a convenient, chainable API as well.
Here's an example of the default output and levels.
It's called Adze and you can find the docs at adzejs.com/ .
You can also find the GitHub repo at github.com/AJStacy/adze .
If you find it useful, please give it a star on GitHub!
Hi there! Nice topic.
A:
I currently use a library I've been working on and maintaining for the last 2 years, its called Loggin'JS github.com/loggin-js/loggin-js. I mostly use it on NodeJS apps, but it also has support for the browser.
B:
In the browser I usually use logging as a debugging feature as tux0r said in another comment.
But if I make some kind of cli app for example, I will structure logs much more and separate them between user and debug logs, I usually save them all to log files, but only show specific logs to the user, as this lib makes this really simple. I also give the option to manage what logs the user want to see.
C:
If I'm working on the browser I usually don't store my logs, but on NodeJS apps I mostly save them on files or on some database like mongo-db, which this lib has a plugin to do so.
For all you guys out there using the
consoledirectly, because you don't want to commit to some logging library, I came up withanylogger. It is a ~360 bytes minified and gzipped logging shim that wraps the console. But it is also a facade object that supports an adapter pattern to plug in support for the logging framework of choice.For example, if you were building
my-library, you could installanyloggerlike this:Then in your code, you would create and use a logger like this:
my-library.js
This adds a tiny, ~360 bytes overhead to your library, but you now have configurable logging support. Suppose you discover you really like
debugand want to use it in your new project that is usingmy-library. Here is how you would installmy-libraryinto your application project and make it usedebug:This installs
my-library,anylogger,debugand theanylogger-debugadapter.Then, in your main.js, just require the adapter and it will work:
main.js
I am working towards an 1.0 release and would appreciate feedback.
It is an example. The point is that if you do expensive things to produce the arguments of a log call, the fact that the log function is a no-op does not help with performance. In such cases you need the if. The example is there to demonstrate the if.
I have, a long time ago, registered the NPM package name anylogger, because basically logging in JS is a royal mess. If you build an app out of a few dozen packages, chances are you end up including 5 different logging libraries because every module chooses it's own logger.
Wouldn't it be much better if libraries would use a facade to log and leave the choice of the actual logger (and it's config) to the final app? A bit like what SLF4J is doing in Java land, but much simpler of course ;)
This is what anylogger is supposed to be... a Facade that libs can use and that can be replaced by a real logger like Winston, Bunyan, Loglevel, Debug, or, of course, Ulog.
If you are interested in this, please check it out. It's mostly in pipe-dream stage at the moment though. But I would love to hear feedback on this.
Please, please try ulog It is just over 1KB and it supports all this stuff out of the box. Plus it has a test suite and everything and does not have the bugs your home-brew implementation will have. I am speaking from experience. I have been developing this simple lib for years now and it is amazing how many things can (and will) go wrong in different environments when it comes to logging.
Basically I am hearing you guys re-inventing the wheel :) ulog has a simple config mechanism via env vars or localStorage that does exactly what you mention here, plus a bit more. Check it out and let me know what you think.
About the no-op thing.... It is probably just minimal overhead, not no overhead. But really if the overhead of an empty function call is an issue in your code, better look very carefully at your code because that should never be an issue.
What could be an issue is if you do this:
The
veryExpensiveFunctionCall()will be performed and the result passed to the no-op method... So still slow.In
ulogwe fix that like this:The level check makes sure we only call
veryExpensiveFunctionCall()if it is really needed.The problem with using console directly is that there are browsers out there (probably only real old ones though) that simply crash your code right away because console is undefined when the developer tool is not opened. Also some interpreters, such as Nashorn which comes with Java, simply do not have a console defined.
If you want to avert that risk and still only use the console for logging, you should write code similar to this:
However, this means testing
logbefore each call tolog.info... You could maybe do this to prevent that test:However, you would also have to make dummies for warn(), error() etc... In the end you would be building a shim... Which is exactly how ulog started. I understand your desire to keep logging simple and not use any external libs for it... But really the state of JS today is that 'simple' logging either is broken (crashes on some systems), is not actually 'simple' (see code examples above), or does use a library. I built ulog from the desire to make it as close to using no lib at all, while actually solving those problems. If you never use any logging lib, ulog was built with you in mind! Please try it and let me know.
Before I proceed I must warn you I am the author of the logging library I am using, so there is a tiny possibility that I might be biased. Very tiny :)
ulog - The microscopically small universal logger
Basically ulog is debug meets loglevel meets the console. It works in Node JS and all major browsers (even old ones!)
Why I built it
It started out because using console directly is basically VERBOTEN. Because some browsers simply don't support it and will crash your code. Also you need to remove these statements afterwards etc. Making logging difficult and error prone. So it started as a tiny shim that just makes sure that your code never crashes or fails whether console is available or not.
I then decided I wanted log level support so I added that. And then I discovered debug, which is GREAT, and I decided to copy those features I loved about that.
Why I think it is one of the best loggers
Example usage
Yields (on browsers)
If you want to try it
Now is the perfect time as I am trying to perfect v2 currently. So if you want to try this, please install the beta and let me know:
Or you can use v1, but that version is more limited in features:
Haven't heard of Winston before this post. Looks really cool for creating log files based on the
consolestatements used in the code!