Extends array not merging as expected

[adambullmer]

Expected Behavior

When using multiple extends configs, I expect the last config to override any previously specified setting from the previous config(s).

Current Behavior

Some settings (in my case the parserPreset) are being overwritten by the last config option, while others are not (a rule).
Given a config like in the example below, I expect the enum-types rule to override the one specified in @commitlint/config-conventional.
When reversing the extends array, which solves the rule merging, I expect the parserPreset override to be the one from semantic-commit-emoji

Affected packages

• cli
• core
• prompt
• config-angular

Possible Solution

Refactor config extends loading and merging? Looking at transpiled code, in resolve-extends, your reducer is transpiled as reduceRight which seems backwards from what was originally authored in source.

Steps to Reproduce (for bugs)

Knowing that types is a type added by semantic-commit-emoji and absent in conventional-changelog, you can reproduce the issue and get an invalid type with: git commit -m "types: Foo"

commitlint.config.js

```js module.exports = { extends: ["@commitlint/config-conventional", "semantic-commit-emoji"], }; ```

Context

Using community defined presets/plugins, I cannot use compatible rules and parsers necessary to run.

Your Environment

Executable	Version
commitlint --version	9.1.2
git --version	2.21.0
node --version	14.13.1
yarn --version	1.22.10

[escapedcat]

Hey @adambullmer , have a look if this issue duplicates #2069. For #2069 this was already merged but not yet released: #2070

[adambullmer]

Well, that would explain the disconnect of reduce vs reduce right, but doesn't explain why some config attributes merge one way and others merge the opposite.

I'd be happy to test with the latest and report back if it solves the issue at hand though

[escapedcat]

Alright, got it.

I'd be happy to test with the latest and report back if it solves the issue at hand though

That' would be great! Not sure when the @next-release release though. I'll try to let you know here.

[adambullmer]

testing the reduceRight -> reduce change locally seems to resolve all of my configs correctly. If you're waiting to release because of breaking changes, it looks like this single line change fixes my original issue of the wrong merge order for the parserPreset (but right order on rules). Changing that should be a backwards compatible fix. but could break some people's configs if they relied on the incorrect behavior.

Ultimately up to you all the maintainers on when you feel comfortable introducing changes that will change the output of the loaded config. But thank you for hearing me out and I look forward to the @next release