Passing options down the pipe

[clibu]

It would be useful to be able to pass options along the pipe.

For example Human has an option color as does Browser, which would typically be set the same. Both default to true, however if you want them to be false then you need to include { color: false } for both.

Instead if Human( opts ) could be passed to Browser etc. both client code and usage would be simplified as { color: false } would only need to be specified once.

Similarly it would be handy if LogEntry could be passed down the pipe then the Browser transform could access LogEntry passed to Human().

Finally it would be useful if Transform's could access Logger options.

I do however realize that these suggestions maybe outside the design scope or even unwanted.

[balupton]

Prior to version 6 we had configuration piping, however it was removed as it was too difficult to reason about and maintain. Much clearer for options to not be inherited and merged, or at least leaving such to userland instead of core where they know the assumptions about merging and inheritance.

Similarly it would be handy if LogEntry could be passed down the pipe then the Browser transform could access LogEntry passed to Human().

This would be a seperate thing, however I think it would also complicate matters as we need the pipes compatible with normal node and deno piping. Perhaps human could extend the log entry rather than convert it, however performance is critical as some apps do thousands of logs in a few seconds, and extensions would still not output the expected result when piping human to say stdout.

[clibu]

Ok. It is interesting that I've come along after the fact and suggested something that was in place earlier. That would suggest there was and possibly still is a need. However I completely understand your position and am fine to just move on.

I've made extensive changes to copies of Human and Browser to enable all ansi colors and styles to be used everywhere, and along the way simplified the code. However the Browser output is overly noisy as all objects are expanded, which I'm not used to. This makes sense in Node, however in the Browser simpler logging lets the user interactively expand and collapse objects which presents a far more compact (less noisy) output.

So I'm now working at implementing an option for this simpler Browser logging style. However because of the loss of information piped from Human to Browser, it looks like I need to combine the two transforms into one. I'll keep you posted.

Here's my updated Browser output:

and this show's all the Log Levels:

[balupton]

The browser transform and the hunan transform could certainly be merged. The plan would be for an ansi package that outputs the style for the browser if in a browser environment. And either the one package does it automatically, or you configure the new human transform with the appropriate config for the environment.

[clibu]

Yes, I'm using ansicolor which replaces your ansi code. Works a treat.

I now have a combined human and browser module called superHuman 😀 which has target (browser/node) options amongst others. It's coming along nicely.

It can either do the original colored and expanded output or the user expandable compact output like this:

[balupton]

Lookin good