CLI: Better printing of objects

Right now if you logger.log() an object, the logger will decide whether to stringify it the output in stdout.

If we stringify (as we do by default), the output in the terminal is a JSON string. Which is kinda ugly because of all the quotes and won't have any colouring or anything.

If we don't stringify, then node's default util.inspect will kick in. But this will only show 2 levels of nesting:

It also sort of bugs me that maybe the object will be printed on one line, maybe not, depending on break settings I think.

Neither option is actually terribly good.

Solution 1: Expose console.dir

One way a user can solve this today is to do console.dir() or util.inspect() (which are basically but not quite the same thing) in their job code.

This explicitly lets the user control coloring and nesting depth. One difficultly is that while console.log() takes many arguments, console.dir() only takes one. So it's not 1:1 usage.

Obviously this doesn't help adaptor code, which may need to also use console.dir. So adaptor errors would need patches to improve.

I'd prefer not to do this stuff. I just want console.log(obj) to send out a readable object in any context, no matter how big it is or where it comes from.

Solution 2: set our own inspect rules

If we're in control of the logger (and for job code we are), we should be able to intercept the log output and divert to console.dir on our own terms.

Or even better, for every logged object, write a util.custom.inspect function just before it gets sent to the logger. Or make all objects subclass our own LoggableItem, or something.

We may have to work out how to handle circular references.

We may have to add options like "only print n items in an array" or allowing users to specify the depth through the CLI.

I think one benefit of this approach is that if you do console.log("err", e) - ie, a string and an object - the object should still pretty print.

Note that in the CLI right now, this doesn't' help us with adaptor console.logs. If you do console.log() from adaptor code, it does not go through our logger, it goes to normal stdout. In the worker we intecept these calls through the child process and force them into our logger - but the CLI hasn't worked out how to do that yet.

Solution 3: Use console.dir internally

When a single object is logged, call console.dir instead of console.log. We'd have to work out how that fits with levels - I guess we check that that level is valid and call console.dir if so. It doesn't matter much with console.error because we send that to the stdout stream anyway/.

Again, this only works through our logger - it doestt' work with adaptor logs right now.

Solution 4: Maybe set a node default?

I'd love to set a flag on node.js itself and tell it use a different default depth.

If this setting exists I haven't found it yet.

The benefit of this approach is that it should apply equally to adaptor code and job code.

Related

• Support logger.dir() to give users some control over output - although tbh this really shouldn't be necessary, our runtime should just handle it,
• Add options to the CLI along the lines of --log-inspect and --log-stringify (current behaviour), which allows the user to control whether or not we stringify objects

Worker & JSON Mode

This does not affect the worker at all.

When the logger runs in JSON mode (as it does with the worker), objects are not stringified at all. Their passed straight through verbatim.

I suppose we should consider using inspect or dir for all output in json mode in the CLI, because lookiig at the stringified JSON output is horrible. If every log line is an object anyway, we may as well use inspect to show it more nicely?

Start at the CLI logger handling for logger.log(), then compare the console.dir and util.inspect behavior described in the issue, including mixed string and object arguments. Check the CLI's non-JSON output and the worker's JSON mode; done means a decided, readable object-printing behavior for CLI logs without changing worker JSON behavior.