Feature/separate files #492
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello! I've come across a use case where it would be nice to have one output file per input file. I'm setting up a static documentation site for Proto files and the UX is better when the output mirrors the input instead of having them grouped together on one page (regardless of using
source_relative
or not).Summary
This PR adds support for a
separate_files
flag which outputs one file per input file instead of grouping input files into one output file.Usage:
This would output:
Notes on Behaviour
md
like in the example above, the output files would be<filename>.md
.source_relative
or without, it does not changesource_relative
's functionality.Testing it Out
I was testing using this command from the repo root:
Additional Notes on Implementation
I've kept the same convention of adding another parameter to the
--doc_opt
list. I can foresee this becoming hard to manage in the future since a) parameters are mapped to indices which makes the code ugly as you gain more parameters and b) usage-wise you must specifydefault
for previous parameters you may not care about. However, I didn't want to make assumptions on the grander vision of this API (and also introduce a lot of out-of-scope changes) so I just followed the convention.I'm an iOS developer and Go is a little foreign to me, so please feel free to give feedback on conventions or anything else that doesn't seem to fit quite right. Thanks!