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)
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)