let's figure out an elegant way to support sites other than github.com

[bcoe]

it was my goal with standard-version to avoid the paradox of choice ... less can be more, I didn't want people to have to configure 1,000,000 dials and knobs to get a lovely looking CHANGELOG and to automate their release process.

Having said this! It would be nice to support version control systems other than GitHub; specifically we have some issues open around adding better support for gitlab and BitBucket/jira.

The question I put to folks (@Tapppi, @stevemao, @cdupetit, @lancecaraccioli) is what's the minimum amount of configuration settings that we would need to provide to generate an appropriate CHANGELOG for these alternate version control systems; where possible I'd like to try to:

1. extend the logic of the base template that we use (rather than forcing users to configure an alternate template).
2. add more magic to standard-verison itself, to try to detect the reasonable defaults for settings, e.g., what's the host of the repo that we're working in.

Once we pin down the minimum # of variables that we need to make flexible, let's allow these to be set using a standard-version key in the package.json -- this work dovetails nicely with the work @lancecaraccioli has been doing on lifecycle hooks.

[stevemao]

We can detect the "bugs" url in package.json. If the base url is different than "repository", use that for issues. The references to the PR should be the same as is.

[lgomez]

Hi there...

When you say:

rather than forcing users to configure an alternate template

What do you mean? How are you forcing people to configure a template? I've yet to find how to override the base template. How does one do that?

[bcoe]

@lgomez we don't currently support swapping out this configuration setting. Basically, I'd like to figure out a minimal set of configuration settings that we should expose in standard-version without it becoming overly complex.

[lgomez]

All I wanted was to replace or eliminate the header and footer from the default CHANGELOG.md template.

Perhaps describing my ideal scenario would help...

// In package.js...
"scripts": {
  "release": "standard-version --template=my/custom/template.hbs"
}

If the template uses partials, I would include the partials wherever the template can reference them.

The other thing I was trying to figure out is if there is a json output of changelog data so I could achieve the same thing but handle the handlebars and templates myself and just pass that changelog object to handlebars.

Hope this helps...

[bcoe]

@lgomez for your use-case, I think it might be worth looking at:

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

Which uses many of the same core libraries as standard-verison, but is much more configurable; the goal with standard-version is to have as close to zero configuration as possible; so I'd adding many additional modes of operation, e.g., JSON output; but, you should be able to get this functionality using various other modules in the conventional-commits ecosystem.

[brettp]

Are there any plans to introduce this, or at least guidance to create a PR that may be accepted? Zero config is always nice, but I'd wager most people would enjoy using custom templates, or at the very least a way to prevent the header from being injected, so a quick option to add an argument would be ideal. With current implementation it's extremely bothersome and heavy to make these simple changes.

[bcoe]

@brettp took a while to actually implement it, but we now allow you to customize URLs and other parameters, the configurations settings are described here:

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