Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output stream #1371

Closed
wants to merge 2 commits into from
Closed

Commits on Oct 13, 2020

  1. Add custom output streams to commands

    stdout isn't available to my user.  I have a custom method of displaying text output to the user.  I still want to make use of the full Commander help suite.  Disabling the built-in help commands and writing wrappers becomes an increasingly complicated task when you want to make use of the entire help suite.  This PR will solve that problem by removing the assumption that all output is to `process.stdout`.  A user can instead pass a writeable stream that will replace the default stdout stream.  In this way, anyone can output command results in any way that works for their use case by defining their own writeable stream.
    
    This is a more elegant solution to the problem in tj#1370.  Instead of using `helpOption(false)` and writing my own help option, I can use Commander's help option, and handle the output with my own writeable stream.  This is a less invasive solution than tj#779, as it leaves the implementation of the writeable stream to the user.
    
    Suggested changelog: "allow overriding the output from default (`process.stdout`) to any `stream.Writeable`"
    
    Things to note:
    * I've intentionally not updated the README or the examples/, as this is a WIP PR, and I'd like to know if this idea will be accepted before documenting it that far.
    * This adds a dependency on `stream.Writeable`, but that's built into Node, so I think that's fine
    * `process.stdout` is a `stream.Writeable`, but it's also a `tty.WriteStream`.  Only the latter has the `.columns` field in its API.  All of Commander's uses of that field are protected by a default if `.columns` is Falsey.  So for that reason I've kept it simple with the understanding that if someone wants a non-default column width in their custom stream, they can specify that field themself.  An alternative would be to create a type that's just a `stream.Writeable` + `.columns`.  I think this alternative adds unneeded complexity, so I didn't go for it.  However, it has the pro of not relying on the existing `.columns || 80` in the code to prevent undefined behavior.
    Melissa0x1f992 committed Oct 13, 2020
    Configuration menu
    Copy the full SHA
    7df1dc7 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    492ae8a View commit details
    Browse the repository at this point in the history