expose better api for post-import config mutating

[jasisk]

@aredridel and I were chatting about a potential new feature inside kraken to prevent us from having to broganize (wrap kraken opts). One step we could take would be exposing a better signature for config post-import normalization, plus registering more protocols after init but before create.

The first part of that we basically already have. The only change required would be to push the final import into the constructor (and either out of the create method or in addition to it, in order to support asynchronous imports). Then, we could simply add a method in place of using the .promise.

The second part would be a simple method to write.

We already do similar behaviors elsewhere (at least for the second part—double confit stuff in kraken), this would just expose a better api for it.

Thoughts?

[pvenkatakrishnan]

interesting thoughts. one i immediately get is being able to add protocols any time before create... The other 2 about moving import resolution per The only change required would be to push the final import into the constructor and extra merge of config methods, i am unsure i understand completely the needs. More info ?

[jasisk]

More info ?

Duplicate this under this. That way, imports that exist on env and argv happen before that promise is considered resolved.

Then, exposing something a little more legible than:

var config = confit(opts);
config.promise.then(function () {
  // imports have happened at this point
  config.create(function (config) {
    // everything has happened at this point
  });
})

[pvenkatakrishnan]

hmmm today the interface is:

confit(opts).create(function(err, config) {

   ...
});

The create related processing after promise resolution happens transparently within confit. Do you have a sample snippet as to what you were thinking as the desired interface.

[jasisk]

That's totally clear. What I'm describing is a new lifecycle event. @aredridel and I were talking about the ability for modules to self-register in kraken. Having the ability to break into the config after imports are resolved but before other shortstop handlers would help facilate that.

[pvenkatakrishnan]

interesting idea.. Maybe we can chat more in detail. as long as all these modules which want to add into the config signs on the promise (which, I agree, they will need an interface for), we can still maintain the above interface. But how the modules will get access to merge into the app's config is the tougher part...

[aredridel]

Agreed. A set-only interface would be interesting.

[aredridel]

Another possibility is exposing the ability to add shortstop protocols from a config entry itself (yay reflexivity!).

[grawk]

+1

[jasisk]

Nice necrobump, @grawk.