-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
move output information to printer #779
Conversation
cravler
commented
Mar 15, 2018
•
edited
Loading
edited
any comments? |
Is this repository supported? |
The test has failed. |
any news? |
@cravler Or is this primarily an object separation suggestion, rather than a functional suggestion? Edit: that probably sounded a bit blunt, sorry! I am working through backlog of Pull Requests making sure I understand them, so asking lots of questions. |
This separation adds ability to write custom printers without touching the default. In my case I have |
Thanks @cravler. This is quite interesting, but changes a lot of code. Offering customisation by inheritance is also more challenging for future maintenance than a callback. I don't wish to add this at the moment. However we have a variety of requests around help and output. This may get revisited in the future if it can be used to resolve more issues. Thank you for your contributions. |
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.