search

lukeed / ley

(WIP) Driver-agnostic database migrations
MIT License
259 stars 14 forks source link

feat: custom drivers #11

Closed lukeed closed 3 years ago

lukeed commented 3 years ago

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 telling ley: "here use this thing"

By contrast --client and opts.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.

lukeed commented 3 years ago

OK – decided to merge client and driver options!

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 ley otherwise.

The one breaking change is that ley --client <name> and opts.client have been removed! If you previously used either of these, simply use --driver or opts.driver instead with the same value.

Also with this change, --driver and opts.driver can be a filepath (string) to your custom Driver implementation. Or they may be the name of a package (so long as it satisfies the Driver interface). Any string value is passed to require() directly.

Another option to specify a driver is through the ley.config.js file. You may define a driver key that acts identically as opts.driver for programmatic usage. Both locations may contain either a string or a Driver class.

The CLI --driver always takes precedence over the other locations.