jonseymour / idiomatic-console Goto Github PK

idiomatic-console suffers from its own composability problem.

One use case for idiomatic-console is to globally rebind the output of the calls to the global console API to some other place.

Ironically, this becomes harder to achieve as more modules use idiomatic-stdio to manage their own console output, because these modules are no longer directly bound to the single global console object.

I am contemplating a good way to fix this. It may involve overloading the function of lock() to configure the console object that is used to back private console objects (currently they are backed by the original, global console object, in future they may be backed by the object established by lock)

It might be useful to support a factory pattern for private console objects.

This would enable the log4j-like configuration approach, for example.

In the case of redirecting console output to a file, is there any way of prefixing the output with a date stamp before it gets written to the file?

Currently idiomatic-console only hooks log, info, warn and error.

Support for hooking other methods should be added.

Currently, the streams used in the .DIAGNOSTICS and .DATA object are the streams present at the point that the idiomatic-console module was initialized. It would probably be better to defer this initialization until the point of the rebind &/or the point of use since something, somewhere may have decided to patch process.stdout and process.stderr with alternatives.

Consider the best way to do this.

The idea is to allow the default bindings used by a node module to be configured externally, as in a log4j configuration file.

Modules would obtain a private console object, and global configuration would determine how that console object behaves. Adapters could be built for popular node.js logging systems.

was https://github.com/jonseymour/node-idiomatic-console not https://github.com/jonseymour/idiomatic-console

I am going to make the following changes.

• to enforce the rule that at most one top-level module can globally rebind the console object, there will be a pattern like this:

var unlock = console.lock();
try {
   // application code.
} finally {
    unlock();
}

• push() and pop() wil be removed from the public API.
• the API produced by rebind() will inherit always inherit its prototype more or less directly from the global console object
• the API produced by rebind() will always inherit bindings from its parent

Define a NULL bindings constant that can be used to suppress all console output.