-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: custom drivers #11
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! I'm a fan of dropping client
.
Allows users to supply custom drivers, so long as they adhere to the
Driver
interface.CLI users can use
--driver <name>
to autoload their driver by name.Programmatic users can supply
opts.driver
to any command.Defining a
driver
at all skips client auto-detection, since you're tellingley
: "here use this thing"By contrast
--client
andopts.client
is meant to load an internal/off-the-shelf driver....Will come back to this. I think
client
&driver
should probably be merged as a single "driver" option.