Recommended approach to logging?

#1

Does anyone have a package to recommend for logging? Or is there already something built into Atom for this?

Specifically, I want to have the option to log a lot of stuff, so I don’t want to write it all via console.log() (that’s obnoxious for other package developers). I would rather write out my logs to a file that can be included with bug reports. It would be nice if the logger supported the same format strings that the Chrome console API does, as well as the ability to set a logging level for different namespaces like in Java.

There’s also the issue of configuring the logger. Assuming I have multiple packages that want to share the same logging infrastructure, how would I do that? Last I checked, the order of activation order for Atom packages cannot be controlled, so I’m not convinced that I can ensure that my logger is configured in one package before it is used in another.

Thanks for any suggestions!

#2

Ah, I just grepped Atom’s package.json for log and discovered https://github.com/atom/node-nslog.

#3

Upon further inspection, node-nslog does not appear to be what I’m looking for.

#4

https://www.npmjs.org/package/log4js looks promising.

#5

I’m sure npm has a zillion logging packages. Any should work in Atom.

#6

@mark_hahn I don’t believe that’s true. For example, Atom v0.138.0 introduced the reuse of required modules, which means it is easy for one package to clobber another’s logging configuration if they both depend on log4js. This problem seems unique to Atom, but not Node.

/cc @kevinsawicki

#7

I had an extended argument on the atom/atom issues list where I claimed modules would clobber each other if they shared module objects. I gave up after I looked through a lot of modules and couldn’t find an example. In every case a class or closure provided isolation because the instance was unique to the using module.

Are you sure log4js has this problem? I would think each module using it would get their own logger instance.

#8

If you look at the sample code, there is a configure() method. If you look at the implementation of log4js.js, you can see that configure() calls configureOnceOff(), which calls configureAppenders(), which calls clearAppenders(), so yes, there is a static configure() method that blows away all previous configuration.

This is pretty common for a logger because it’s really annoying to have to pass a logger from above all the time since it’s used everywhere, so static methods, as distasteful as they are, are commonplace in logging libraries.

#9

I would argue that the limitation on expressing package dependencies exacerbates this issue.

#10

It is interesting that you bring this up. @leedohm, @postcasio, and I have been working on extending Lee’s bug-report package. We added a mechanism where other packages can add information to the automatically generated bug report. The error-status package now (well when released) has a button to fire up bug-report which includes the console error message and stack in the report.

To make a long story short I have been thinking that it would be nice if logs could also be added. In order to do this there would probably be a need for a standard log format, at least for how it is sent to the bug report.

I like your idea of making it console compatible. Maybe we should take one of the good log modules, fork it, and customize it for use in Atom and with bug-report. Or just do it from scratch.

I’d be happy to contribute. I’ve already contributed to error-status to work with bug-report.

#11

FWIW, I filed a bug against log4js to introduce an appendConfiguration() method. I would rather improve an existing logging package than introduce yet another one.

Though if one were built into Atom, that would be even better. There is still the issue of resolving the race condition of configuring the logger in one Atom package before using it in another.