Bootstrap and custom plugin configuration

[naxhh]

Hi everyone.

Our company is using commitizen for one of our main OSS project but we slowly started using it in smaller projects and tools.

We now require a standard commitizen configuration in order to keep all projects the same way. Our current solution has a lot of configs and is not working very well for us.

For context we are using:

• Commitizen
• cz-customizable
• validate-commit-msg

Each of this packages has it's own config. for sake of conventions I've started creating our own tool to manage commits (an adapter of comitizen) the goal is to keep all the configuration hidden for the end user as much as possible.

I've seen the bootstrap and as far as I can see in the code this are the options you can give:

  debug: false,
  cliPath: path.join(__dirname, '../node_modules/commitizen'),
  config: {
    "path": "cz-customizable"
  }

Now my current problem. cz-customizable right now reads from a config file specified in the package json.

I think bootstrap should be able to send all this configuration options to the adapter, but right now the project only uses the path and instances the prompter.

I was thinking on something like:

function getPrompter(adapterConfig) {
  var resolvedAdapterPath = resolveAdapterPath(adapterConfig.path);
  var adapter = require(resolvedAdapterPath)(adapterConfig);
}

or

function getPrompter(adapterPath, adapterConfig) {
  var resolvedAdapterPath = resolveAdapterPath(adapterPath);
  var adapter = require(resolvedAdapterPath);

  if (adapterConfig && adapter && adapter.setConfig && (0, _util.isFunction)(adapter.setConfig)) {
    adapter.setConfig(adapterConfig)
  }
}

First one breaks all the current adapters, so I understand no one is eager to do that. The second one works without breaking anything since I think most of the adapters do not require a config?

What do you think about it? is something you will like to see for adapters? Or maybe I should create my own adapter for the company? I was thinking on this because cz-customizable has all we need, but it lack the ability to get config from bootstrap

[jimthedev]

Although I haven't confirmed that the code works yet, I like the second option because:

1. a path will always be required for commitizen to work so keeping it as arg1 is good.
2. I prefer to keep userland adapter bootstrap config separate to prevent namespace collisions. This would allow the config to have a property called path (or anything) without having to worry about future prop names that commitizen might implement.
3. It allows for a happy path but also allows authors to opt in for additional hooks.

Do you think that we should allow the adapter config to be either an object or a promise? I don't know if these configs will be loaded async?

[naxhh]

Not sure if I see a case that a promise would be needed, but I can only speak of my case

[hassankhan]

Hi @jimthedev, would also like to echo a similar sentiment. I don't necessarily know if this is possible, but I thought something like the following:

Custom Adapter:

export const prompter = (cz, context, commit) => {
  const prompts = createPrompts();

  const { foo, bar } = context.config['@myscope/my-adapter'];

  return cz
    .prompt(prompts)
    .then(formatCommit)
    .then(commit);
};

Configuration File:

{
  "path": "@myscope/my-adapter",
  "@myscope/my-adapter": {
    "foo": 1,
    "bar": 2
  }
}

Where context.config would be the Commitizen configuration file (.czrc). However, I'm not sure we can overload the prompter signature like that without a breaking change 😞

[drewrawitz]

Just wanted to check in and see if this has made any progress. I'm also needing a way to specify some config settings for the cz-emoji and I can't seem to do it from the bootstrap file. Thanks!

[hassankhan]

@drewrawitz you could do something similar to what I ended up doing for cz-github.

[william-will-angi]

Would also like to see this feature -- Trying to get profiling information on how long it takes users to use the cz-cli, but can't properly track that information without a callback or promise implementation