Repository navigation
Conversation
simonjbeaumont
left a comment
There was a problem hiding this comment.
Hm, I've approved this, but I think I would prefer it if we just had dry run print the files to stdout. Seems like these two options are pretty overlapping.
simonjbeaumont
left a comment
There was a problem hiding this comment.
OK, we discussed this offline a bit and think the better approach would be to not add an additional option but to have the CLI behave like a better CLI citizen. Concretely that when run:
- All logging should go to stderr
- All output should go to stdout
I think we've already tried to make (1) true. We have a stderr diagnostic handler and the log function in the plugin code goes to stderr, so we might just need to validate this and catch any stragglers.
For (2), I'd argue a code generator tool's output should be the list of files it generates, written to stdout, one per line. It's defensible to have some kind of format option in the future, but for now one file path per line is reasonable. It allows for the command to be piped to other commands, which is conventional for a well-behaved CLI.
Then we can expect that the only thing on stdout is the list of files regardless of whether it's run with --dry-run or not ("wet run"? 😶).
Adopters that want to just list the files can then just run with --dry-run and capture the output.
Motivation
Some build systems require knowing the output file list in advance.
Modifications
Allow listing it with
--list-output-files. It skips the actual codegen work completely.Result
Easier to integrate from alternative build systems.
Test Plan
Added unit tests.