conventional-changelog-conventionalcommits v8.0.0 breaks semantic release

[ryancausey]

It looks like v8.0.0 of conventional-changelog-conventionalcommits was released about an hour ago. This causes the semantic-release "generateNotes" step of plugin "@semantic-release/release-notes-generator" to fail:

$ npm --version
10.5.0
$ semantic-release --version
23.0.8
$ semantic-release
[11:48:10 PM] [semantic-release] › ℹ  Running semantic-release version 23.0.8
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/changelog"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/gitlab"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "verifyRelease" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/changelog"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/git"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/gitlab"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "success" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "success" from "@semantic-release/gitlab"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "fail" from "@semantic-release/exec"
[11:48:11 PM] [semantic-release] › ✔  Loaded plugin "fail" from "@semantic-release/gitlab"
[11:48:15 PM] [semantic-release] › ✔  Run automated release from branch master on repository [https://gitlab-ci-token:[secure]@gitlab.com/foo/bar.git](https://gitlab-ci-token:%5Bsecure%5D@gitlab.com/foo/bar.git)
[11:48:15 PM] [semantic-release] › ✔  Allowed to push to the Git repository
[11:48:15 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/changelog"
[11:48:15 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/changelog"
[11:48:15 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/exec"
[11:48:15 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/exec"
[11:48:15 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/git"
[11:48:15 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/git"
[11:48:15 PM] [semantic-release] › ℹ  Start step "verifyConditions" of plugin "@semantic-release/gitlab"
[11:48:15 PM] [semantic-release] [@semantic-release/gitlab] › ℹ  Verify GitLab authentication (https://gitlab.com/api/v4)
[11:48:15 PM] [semantic-release] › ✔  Completed step "verifyConditions" of plugin "@semantic-release/gitlab"
[11:48:15 PM] [semantic-release] › ℹ  Found git tag v1.4.0 associated with version 1.4.0 on branch master
[11:48:15 PM] [semantic-release] › ℹ  Found 1 commits since last release
[11:48:15 PM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[11:48:15 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: fix: make the esg rule name not clash with other domains
This was not applying properly because the rule has the same name as a
rule created by a different AWS account on the same bus.
[11:48:15 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[11:48:15 PM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 1 commits complete: patch release
[11:48:15 PM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[11:48:15 PM] [semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/exec"
[11:48:15 PM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/exec"
[11:48:15 PM] [semantic-release] › ℹ  The next release version is 1.4.1
[11:48:15 PM] [semantic-release] › ℹ  Start step "verifyRelease" of plugin "@semantic-release/exec"
[11:48:15 PM] [semantic-release] › ✔  Completed step "verifyRelease" of plugin "@semantic-release/exec"
[11:48:15 PM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[11:48:15 PM] [semantic-release] › ✘  Failed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[11:48:15 PM] [semantic-release] › ✘  An error occurred while running semantic-release: RangeError: Invalid time value
    at committerDate (/usr/local/lib/node_modules/semantic-release/node_modules/conventional-changelog-writer/index.js:80:30)
    at /usr/local/lib/node_modules/semantic-release/node_modules/conventional-changelog-writer/lib/util.js:202:17
    at Array.forEach (<anonymous>)
    at processCommit (/usr/local/lib/node_modules/semantic-release/node_modules/conventional-changelog-writer/lib/util.js:198:31)
    at /usr/local/lib/node_modules/semantic-release/node_modules/conventional-changelog-writer/index.js:123:32 {
  pluginName: '@semantic-release/release-notes-generator'
}
RangeError: Invalid time value
    at committerDate (/usr/local/lib/node_modules/semantic-release/node_modules/conventional-changelog-writer/index.js:80:30)
    at /usr/local/lib/node_modules/semantic-release/node_modules/conventional-changelog-writer/lib/util.js:202:17
    at Array.forEach (<anonymous>)
    at processCommit (/usr/local/lib/node_modules/semantic-release/node_modules/conventional-changelog-writer/lib/util.js:198:31)
    at /usr/local/lib/node_modules/semantic-release/node_modules/conventional-changelog-writer/index.js:123:32 {
  pluginName: '@semantic-release/release-notes-generator'
}

Reverting conventional-changelog-conventionalcommits back to the v7.x.x series makes this release run fine again.

[jedwards1211]

I had the error even with conventional-changelog-conventionalcommits v7.x.x; it seems like it was being caused because the preset I was using with @semantic-release/commit-analyzer didn't match the preset I was using with @semantic-release/release-notes-generator. When I made them match, the error went away with v8.0.0.

[ryancausey]

I had the error even with conventional-changelog-conventionalcommits v7.x.x; it seems like it was being caused because the preset I was using with @semantic-release/commit-analyzer didn't match the preset I was using with @semantic-release/release-notes-generator. When I made them match, the error went away with v8.0.0.

I'm not sure what that means. I simply have a preset: conventionalcommits at the top of my .releaserc.yml file, so I would assume they all share the same preset?

[jedwards1211]

@ryancausey Oh, I'm not sure, I'm configuring all the plugins explicitly, and the plugins accept the preset option.

[travi]

the conventional-changelog packages released new major versions. that means they include breaking changes. since they were just released, no work has been done to make adjustments to account for the changes in semantic-release.

if someone would be willing to investigate what changes would be needed, that could help us adjust for these changes sooner

[jedwards1211]

@travi yeah that makes sense. If we need to customize the preset though, we have to install it, and then it's easy to install the wrong version... so should we make this package check the version of the preset at runtime, and at least print a warning? I would almost suggest we put the compatible version in optionalDependencies, but package managers, confoundingly, install optional dependencies by default. So the best I can think to do is a runtime check. I'd be happy to make a PR.