The compiler will now support multiple values passed to an option at the command line using a comma-delimited string:
--option my-emitter.foo="three,four,five"
Multiple specifications of the same option will not aggregate arrays of values across of them. The newest one always wins.
Simple backslash-escaping of commas will be needed for strings that should not be treated as arrays
Other notes from the design meeting:
Notes:
The future is using TypeSpec instead of JSON Schema, may be opportunities to drive better CLI parsing.
Can we perhaps just pass through string arguments to the emitter and let it handle it? It's possible, though maybe some downsides > (e.g. consistency of command line args, every emitter implementing splitter logic).
Type-directed arg parsing would allow us to use the option schema to interpret the CLI command more rigorously, passing emitters > scalars or arrays as necessary.
Possibly be consistent with yargs/azd? Spaces for separate args.
Preferences:
Preference for handling this in the compiler as opposed to passing through to emitters and having them parse it.
Preference for string-with-commas: --option my-emitter.foo="three,four,five".
Later, express options in TypeSpec, support aggregation, etc.
markcowl
commented
1 year ago
The approved design (for now) is the following:
The compiler will now support multiple values passed to an option at the command line using a comma-delimited string:
Other notes from the design meeting:
This is the implementation issue of #2092.