User input

[cristovaov]

Hi and thanks for letting me participate in the conversation!

So below is a representation of what's in my head when reading your previous discussions around a custom configuration. I've written it out in json format for illustration purposes:

"standard-version": {
  "changelog-convention": {
    "include": 
      ["docs", "style", "chore", "refactor", "test", "build", "ci"],
    "extend": { "other": "Other" },
    "issueUrlFormat": "" ,
    "commitUrlFormat": "",
    "compareUrlFormat": "",
    "releaseMsgFormat": "release: {{releaseTag}}"
  }
}

include key (core types): takes an array of strings matching core convention types that are not included by default in CHANGELOG.md. It is based on the defaults presented in issue #1 :

type	name	include
feat	"Features"	true
fix	"Bug Fixes"	true
perf	"Performance Improvements"	true
revert	"Reverts"	true
docs	"Documentation"	false
style	"Styles"	false
chore	"Chores"	false
refactor	"Code Refactoring"	false
test	"Tests"	false
build	"Build System"	false
ci	"Continuous Integration"	false

extend key (user-defined type):
an object with key-value pairs of <type>: <name> to be added in CHANGELOG.md as well. The extend objects default to minor updates (unless the user overrides it with the --release-as flag) and should accept a scope like core types do. example commit message: other(scope): the message.

releaseMsgFormat key (variable): Alongside the suggested variables in issue #1 - and left empty above, being able to set a release commit message would be a nice thing to have. Currently I do a dry run first and then cut the release with the --message flag.

in this and this comment the idea floats in the air to drop the name key or appellation but I feel that it is more meaningful and important than section, ie: thenamekey-value sets the output of the type in the changelog. But perhaps this is more of a personal thing.

I’m eager to receive your feedback on this input!

[cristovaov]

ping? :wave: :) @bcoe @jbottigliero

[jbottigliero]

Hey @cristovaov – I believe your include proposal is covered by the types and sub-type objects in the initial version of the spec referenced here

If I'm not mistaking, this should also cover the proposed extend attribute.

releaseMsgFormat – this seems like something we should add and potentially an oversight in the initial proposal, thanks for mentioning it!

[jbottigliero]

Ah, I think I misinterpreted your suggestion @cristovaov. The standard-version --message flag is just for the release commit message. I was originally thinking of the version-title sections that appear in the CHANGELOG.md (eg. the heading: 4.0.3 (2019-02-14))... which is probably something we need to account for as well.

I've opened #6 which adds releaseCommitMessageFormat... it's a bit verbose, but that might be ok?

[bcoe]

@cristovaov :wave: did you see @jbottigliero's addition of releaseCommitMessageFormat introduced in #6?

If this would give you the flexibility you need, let's work on implementing it in standard-verison; perhaps open an issue on that project as well?

[cristovaov]

@jbottigliero Verbose is okay! I should have written it verbose from the start to avoid confusion (and like I was taught! :smile: )

The include from my write up is indeed covered by the types and its hidden property of the spec as written in v1.0.0.

About the extend key from my write up: As defined here and from the JSON schema here, it is not clear to me that the array can be extended with custom types. If this is the case, it's perhaps good to explicitly state so in the spec. If it's not the case, I think having a specific property that mirrors the structure of types property would be appropriate.

@bcoe Seen, thank you! releaseCommitMessageFormat is already in standard-version with the flag standard-version --message :+1:

Apologies taking so long to reply whereas I have been previously less patient! :sweat_smile:

Updated core types table:

type	section	hidden
feat	"Features"	false
fix	"Bug Fixes"	false
perf	"Performance Improvements"	false
revert	"Reverts"	false
docs	"Documentation"	true
style	"Styles"	true
chore	"Chores"	true
refactor	"Code Refactoring"	true
test	"Tests"	true
build	"Build System"	true
ci	"Continuous Integration"	true

[jbottigliero]

@cristovaov – thanks for the follow-up, it sounds like we've covered just about everything!

As far as the extends... at the moment, using the exported schema (default properties) directly is going to be the most extensible way for modifying or creating your own presets:

// @my-org/conventional-changelog-myorg
/**
 * the `conventionalcommits` preset is used as the base, 
 * but mostly for writer options to process the `spec` as expected.
 */
const base = require('conventional-changelog-conventionalcommits');
const spec = require('conventional-changelog-config-spec');

module.exports = base({
  types: spec.properties.types.default.concat([
    {type: 'foo', section: 'Foo Things'},
    {type: 'imp', section: 'Improvements'},
  ])
});

There is certainly room to improve on the above implementation, but, I think we'll have to move the preset extend over to standard-version instead of the spec itself to get the desired behavior.

[cristovaov]

@jbottigliero Thx for the pointer on how to extend. It did go a bit above my head on how to exactly implement this :sweat_smile: But I'm a bit further in my project now and decided that what's in the spec is all that's really needed for it.

I think we'll have to move the preset extend over to standard-version instead of the spec itself to get the desired behavior.

Agreed!

Cheers and thanks again!