Note that the current behavior is most definitely 'expected behavior' from the perspective of the commitlint library authors.
I was expecting this module, which is marketed as an adapter for commitizen, to actually use it's main component: the commitizen inquirer.
@commitlint/prompt/src/index.js#L11
export const prompter = async (_, commit) => {
const message = await input(vorpal);
commit(message);
};
It is ignored and another mechanism is used.
If prompt is meant as an alternative way to help fill the template (as suggested by prompt-cli) the commitizen adapter could be another package. You could still keep the original prompt compatible with commitizen for backwards compatibility.
From a naive perspective (this was my first experience with the whole ecosystem) I was expecting the adapter to feed the inquirer based on the linting rules I supplied. Thinking this would prevent me from manually keeping the linting rules and template inquirer in sync.
As I said, it could very well be that the prompt package has a different intention. I am willing to look into making a pull request, but only if the maintainers would agree with and see value in such a package (@commitlint/commitizen).
I first tried prompt-cli and I did not enjoy the experience (which I think is purely taste, so no argument there). I then tried commitzen, which I liked better. Then I thought, it would be great if the template questions were in sync with the rules that I was enforcing. To my surpise (positive) there was an adapter which (in my naive mind) was suited for this situation. This however provided a new surprise (negative) as the adapter pushed me back to the prompt-cli experience.
We should tackle this via two things:
commitizen adapter that uses Inquirer UI. I created a custom commitizen adapter to use internally at Peakfijn. It's loading the commitlint configuration and embeds both the commit types as well as the commit scopes into the inquirer. Finally, it double checks if everything matches the expected outcome by running commitlint against the built message, before actually committing.
Is this how you'd would expect the commitlint commitizen adapter to work @EECOLOR?
Most helpful comment
I created a custom commitizen adapter to use internally at Peakfijn. It's loading the commitlint configuration and embeds both the commit types as well as the commit scopes into the inquirer. Finally, it double checks if everything matches the expected outcome by running commitlint against the built message, before actually committing.
Is this how you'd would expect the commitlint commitizen adapter to work @EECOLOR?