Conversation
note: --driver purposefully overrides `exports.driver` from config file
They were basically the same thing. Now just check if the `driver` string matches a supplied driver name. Customize/override by passing a Driver class or a `path/to/file.js` that contains Driver class.
|
OK – decided to merge Having them separate made for confusing vocabulary, and it didn't really make sense for the internal drivers be kept separate from the rest. The default behavior doesn't change. The internal drivers are still auto-detected if nothing was passed in to tell The one breaking change is that Also with this change, Another option to specify a driver is through the The CLI |
TehShrike
left a comment
There was a problem hiding this comment.
This looks great! I'm a fan of dropping client.
Allows users to supply custom drivers, so long as they adhere to the
Driverinterface.CLI users can use
--driver <name>to autoload their driver by name.Programmatic users can supply
opts.driverto any command.Defining a
driverat all skips client auto-detection, since you're tellingley: "here use this thing"By contrast
--clientandopts.clientis meant to load an internal/off-the-shelf driver....Will come back to this. I think
client&drivershould probably be merged as a single "driver" option.