Feature request: allow manual formatting of CHANGELOG before committing

[MisterTimn]

In our projects we need to do some manual editing of our generated changelog before committing and tagging. We use this tool right now with --skip.tag, then format manually, git commit amend and then perform a manual git tag vx.y.z to achieve this.

Previously we used a tool that just generated the changelog and then paused to allow edits, waiting for an IO prompt to continue committing.

I was wondering if we could add something similar to commit-and-tag-version or if anyone has ideas how we can already achieve this with a postchangelog script for example (I tried but didn't get anything to work).

I would be happy to contribute to the project but just want to know beforehand if this is something that, when done properly, would get merged.

Example of the suggestion:

> npx commit-and-tag-version --manualChangelog
bumping version in package.json from 5.0.0 to 6.0.0
✔ bumping version in package-lock.json from 5.0.0 to 6.0.0
✔ outputting changes to CHANGELOG.md
⌛  Manually edit CHANGELOG.md, press any key to finalize...
✔ committing package-lock.json and package.json and CHANGELOG.md
✔ tagging release v6.0.0

[TimothyJones]

So, I think this might work for you - https://github.com/conventional-changelog/standard-version/pull/530 - it changes the way that the lifecycle hooks are invoked so that you could run an interactive editing session during the release.

I didn't merge that PR when I reviewed the open PRs to standard-version, because:

• I think it needs to remove the old runExec.js as part of the change as it would be no longer be used (there's a duplicate in runExecFile.js, which seem to differ only in the variable names? That one would still be used, I guess? Not sure if they can all be replaced with the same strategy)
• I wasn't sure what the other implications were of that change, if any. For example, is security more of a concern?

Since it seemed like a niche use case to me and the PR wasn't ready, I didn't look into it further - but if you're happy to do the investigation, I'd be happy to merge it (or an alternative solution to the same problem). I think it is on-topic and it seems like you're not the only person who wants it.

[alerque]

I would also get some use out of this. I routinely --ammend the release commit before pushing the tag.

I would suggest a simpler flow where there is an option flag for --edit-changelog or something like that at it fires off $EDITOR CHANGELOG.md after generating it, then waits for the $EDITOR process to finish before commiting.

[TimothyJones]

I like the $EDITOR CHANGELOG.md idea, but unfortunately I don't think it would work for windows users. As far as I know, Windows has no equivalent of EDITOR or any other way to easily invoke an editor.

If anyone wants to clean up the above PR and submit it, I'd happily accept it.

[alerque]

One option to fill in the gap for people that don't have it set is to use git var GIT_EDITOR. This is a relatively new function but available in current stable Git releases. It abstracts the logic Git does to find some workable editor from $VISUAL, $EDITOR, Git configs or system discovery. Since we know we're in a Git environment anyway we could just use that.

[TimothyJones]

Sounds like a nice solution to me - it would make no assumptions about what shell people were using, so would even work for any (probably hypothetical) shells without EDITOR.

Stackoverflow seems to suggest that windows users will get an error message if they don't do some extra config, but I guess we could detect failure and hint that GIT_EDITOR is missing - which would work for all.

[alerque]

Presumably you can detect failure just by checking if VISUAL and/or EDITOR are set too. Also if git var GIT_EDITOR does fail one would presumably suggest setting EDITOR not GIT_EDITOR. Given that this wouldn't be a default action but one hit when the user adds a --edit-changelog or similar flag I think we can expect the user to make some sort of editor available.

[lozah]

Hello, I was looking for the same feature for our project as generated changelogs sometimes need a little rectification. A more general solution might be to add a flag the same as we have --skip to allow pausing whatever lifecycle we need, and allow the user to make any manual needed changes before continuing.

for example : --pause.changelog