Closed mantoni closed 3 years ago
Hmm, tough call. Using subarg would seem way more flexible at first glance (drivers could change their options and the CLI wouldn't have to be updated at all), but then this raises the question whether drivers would need to / should validate the given options and if we're ok with not having these documented in --help
or similar?
Good call on --help
, didn't think of that. I went with yargs
because it's already a dependency of mocha. It allows us to generate the --help
output the same way as mocha, but it wouldn't have support for subarg
, or wouldn't know how to do it.
However, reading the yargs
documentation, it has it's own concept of building objects. We could use something like --driver-option.engine=webkit
which will parse to { driver-option: { engine: 'webkit' } }
.
See https://github.com/yargs/yargs/blob/master/docs/tricks.md#objects
We could use something like --driver-option.engine=webkit which will parse to { driver-option: { engine: 'webkit' } }.
I think this sounds like a decent option if we get it for free with what we have already :+1:
--decent-option
😆
Changed to use the yargs
dot notation to create the driver options.
Example:
cli/index.js test.js --driver playwright --driver-option.engine webkit
I was thinking how we could specify driver options and pass them down. In this example, I prefixed the
engine
option (used by the playwright driver) with--driver-
.I can think of these naming conventions:
--driver-${option}
--${driver}-${option}
--driver-${driver}-${option}
Or we re-introduce the subarg module and allow
--driver-options [ --engine webkit ]
.What do you think?