As the library gains use, the provisioner constructor function's signature continues to change. This is due in large part to a desire to make the library more configurable. This also means that each new feature that requires a change to the function signature breaks existing callers.
Instead of configuration being handled via unique parameters, a more flexible method should be implemented. A simple solution would be a config struct which is passed as a parameter to the constructor. Nil values should have a default meaning. e.g.:
As the library gains use, the provisioner constructor function's signature continues to change. This is due in large part to a desire to make the library more configurable. This also means that each new feature that requires a change to the function signature breaks existing callers.
Instead of configuration being handled via unique parameters, a more flexible method should be implemented. A simple solution would be a config struct which is passed as a parameter to the constructor. Nil values should have a default meaning. e.g.:
There are also chaining solutions using simple functions to define the target config. Anything is better than the current implementation :smile: