Add the ability to specify Conventional Changelog Options

[cecilia-sanare]

Description

conventional-changelog-cli has the ability to pass in a json file with various configuration options that are passed to conventional-changelog-core. This would be a convenient option for issue trackers and git repositories that don't follow the same standards as GitHub.

Here's an example configuration:

{
  "changelogOpts": {
    "preset": "angular"
  },
  "parserOpts": {
    "issuePrefixes": ["custom-issue-prefix-"]
  },
  "writerOpts": {
    "headerPartial": "{{version}} {{~#if date}} ({{date}})\n  {{~/if}}",
    "commitPartial": "* {{this.subject}} \n\n{{~!-- commit link --}} {{#if @root.linkReferences~}} \n  ([{{hash}}]({{~@root.repoUrl}}/{{~@root.commit}}/{{hash}})){{~else}}{{~hash}}{{~/if}}"
  }
}

[Tapppi]

As standard-version is supposed to be an opinionated tool that guides people to best practices, we have been hesitant about rampant configuration. There has been talk about allowing you to set the preset, maybe along some other options, in a package.json config stanza or maybe an argument. Forking the angular preset and setting your options there would then be the preferred method. Is this what you're looking for, or do you think allowing one to modify all options is somehow necessary (asking for opinions now, as the standard-version team has seems to have been against this idea) in this cli?

/CC @bcoe @nexdrew @stevemao

[cecilia-sanare]

@Tapppi I totally agree regarding guiding users to best practices. I'll give you a bit of information regarding the issue I'm running into.

Problem

standard-version doesn't have support for linking JIRA Issues in the changelog. (from what I can tell)

Obviously to solve this issue I only need to rewrite the commitPartial and issuePrefixes so that issues link to my JIRA instance.

I don't necessarily need to be able to modify the other options.

[patrickmichalina]

I would also like something like this for VSTS online (vnext).

Their URL structure uses commit/{{full_hash}} instead of the partial hash, for example.

This relates to issue #151 as well

[smeijer]

+1, I would like an option to not include any links. This to make it easy to generate public changelogs for a private repo.

[bcoe]

@smeijer @nick-woodward @Tapppi dusting off an old issue as I go through my giant GitHub issue backlog; I don't hate the idea of introducing a .svrc and standard-version stanza in the package.json to standard-version for controlling a few select configuration options.

I think we should make things a bit less À la cart than conventional-changelog-cli; which suffers from the paradox of choice. yargs has great built in support for this functionality.

If an issue doesn't already exist, perhaps we could open one to bike-shed some initial configuration options; mainly I think introducing options that would allow us to support platforms other than GitHub, e.g., BitBucket, would be beneficial.

[markmsmith]

Just to bump this old issue, I would really like for standard-version to allow configuring the parserOpts, as I currently can't override issuePrefixes to handle our jira ticket IDs of RPT-1234 instead of #1234.
I'd rather not eject and have to do changelog generation separately from SemVer bumping, as this is a really great all-in-one project, but without the ability to tweak the config I can't get it to pick up issue references.
Thanks for an awesome module.

[bcoe]

@markmsmith standard-version now allows you to configure a variety of settings:

https://github.com/conventional-changelog/standard-version#configuration

To achieve the behavior you're looking for, you might need to go a step further and create a custom preset, but we do allow you to pass an alternate preset in as a parameter:

Here's a good starting point for writing a custom preset:

https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-conventionalcommits

[markmsmith]

Maybe I'm missing a trick to simplify it, but having to create a whole new preset was a bit heavier than I wanted to achieve this.
It looks like it's already possible to take an existing preset and tweak it via a standard-version stanza in package.json for some of the writer options like commitUrlFormat, so I was hoping for something equivalent for the parser options, eg:

"standard-version": {
  "preset": "angular",
  "issueUrlFormat": "https://jira.mycompany.com/browse/{{id}}",
  "issuePrefixes": ["RPT-"]
}

[bcoe]

@markmsmith this is not something I would like to support in standard-version, as it's being explicitly designed to adhere to https://conventionalcommits.org/ and I think config options that allow folks to completely change these semantics would ultimately create a lot of confusion.

If I can't convince you to use conventional commits (which I'd argue are great 😝 ) I think a preset is probably your best bet -- the conventionalcommit preset should be pretty easy to work from at least.

[markmsmith]

I'm actually on-board with conventional commits - having a standard for consistent tagging & formatting of commit messages to make the semantics explicit is really great!

My constraint is that I have to use jira as our issue tracker rather than github, so need a way for it to detect those ticket references, which have a different prefix (proj-123 rather than #123).

I took another look at the spec and it doesn't seem to mandate a particular format for meta-data, only that it should be in the footer, so it doesn't seem out-of-spec to allow these specializations. If anything, I think this would encourage people to stick with the conventionalcommit preset and not diverge over time just because they're using a different issue tracker.

I think I've made the case the best I can, but I'll accept your judgement on whether this promotes adherence to the standard and adds value to your project. Thanks.

[bcoe]

@markmsmith oh, I understand better, I thought you wanted the commit prefix (fix, feat to be different) -- you're talking about #1, #2, this requirement seems quite reasonable, let's figure out how to build this into the conventional-commits preset -- mind opening an issue there, would happily work on the feature with you.

[markmsmith]

Sure, thank you!

[markmsmith]

I was digging in to the source some more and it looks like the parser supports this, and both conventional-changelog and the conventional-commits preset will pass down the necessary config.

Unless I'm missing something, it looks like standard-version just needs to pass it down here:
https://github.com/conventional-changelog/standard-version/blob/master/lib/lifecycles/changelog.js#L39 or else when the preset is being loaded and configured here:
https://github.com/conventional-changelog/standard-version/blob/master/lib/preset-loader.js#L11

Were you thinking this needed to be a separate config in the conventional-commits preset, or would it be sufficient to just pass down a restricted subset of parser options?

[bcoe]

@markmsmith there's been an effort to simplify the naming conventions used for configuration, and to document every available config setting. Let's decide on a good name for a variable that controls issue format, and document here:

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

And then update the conventionalcommit preset to use it appropriately (ultimately the variable will be passed by the conventionalcommits preset to the parser, I just don't want to expose this interface in standard-version).

[markmsmith]

Sounds good, I'll open an issue on that project, thanks!