Coverage remained the same at 92.12% when pulling e20efe8 on jbottigliero:feat-changelogrc into 558de53 on conventional-changelog:master.

preset: prefix in extend
This seemed like the best option to both specify a current preset and/or extend a preset.

Alternative 1: name

{
  "name": "conventionalcommits"
}

This didn't seem declarative enough and could be potentially confusing when used in conjunction with extend.

Alternative 2: preset.name: <string> or preset: <string>

{
  "preset": "conventionalcommits"
}
// or 
{
  "preset": {
     "name":  "conventionalcommits"
  }
}

A bit more declarative in the preset: <string> form, but still might cause confusion with extend. The object form seems like a non-start, as we basically want the top-level object to represent a "preset".

Alternative 3: extend Without Identifier

{
  "extend": ["conventionalcommits"]
}

Without the identifier in extend it would require additional parsing to determine if it's an attempt to load a local file or a named preset. Additionally, we'd have to make a decision to extend precedence behaviors, which could be avoided...

Also worth mentioning the preset:<string> syntax is influenced by similar behavior in Babel (plugin:<string>)

rather than adding to the fixtures directory, I would be tempted to fork https://github.com/Jimdo/changelogrc-spec into a new directory in the packages/ folder (with publish: false set in the package.json); alternatively, I could create a new top level repo for you to commit to.

I think that the changelogrc-spec, from my point of view, has the right idea of the level of granularity folks will want to modify -- I started implementing support for the configuration here:

https://github.com/conventional-changelog/conventional-changelog/pull/421/files#diff-3ac2e1c1a67d64c40f587c73b9ed4811R125

Introducing a few more configuration options that allow users to edit partials inside templates:

issueUrlFormat, compareUrlFormat, my thinking being this would be an easy way for someone to support gitlab format rather than, as an example, GitHub format.

I think that whether or not this configuration is in a .rc file is an implementation detail, which I'd leave to the upstream implementer like standard-version ... maybe we should call the spec:

conventional-changelog-config-spec?

@jbottigliero I think how this would change your work in conventional-changelog/standard-version#278, would simply be that you pass a different config object to the new conventional-changelog-conventionalcommits preset.

@jbottigliero I've created a repo here, for us here:

https://github.com/conventional-changelog/conventional-changelog-config-spec

to rough out what we think we should expose for configuration, let's move the conversation there.

Catching up on all the latest updates and will head over to the new repository... thanks for triaging!