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%[email protected]/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.

[travi]

@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.

I understand the desire, but npm doesn't provide a great way to define these sorts of relationships. I'm open to proposals as a separate issue if there are options that I'm not aware of, but this is a difficult one to solve. I think the closest might be peerDependencies with meta defining the optional part, but I think there are complexities that make that not ideal too

[travi]

For folks landing here for various breakages related to updating conventional-commits packages before semantic-release is updated to handle the breaking changes, I'm trying to consolidate the conversation in this thread.

Until I get more organized about that, please see my suggestions in semantic-release/semantic-release#3292 (comment)

[jedwards1211]

@travi not sure you saw my suggestion to check and warn at runtime if the preset package being used is not a known compatible version, would you be okay with a PR to do that?

[travi]

not sure you saw my suggestion to check and warn at runtime if the preset package being used is not a known compatible version, would you be okay with a PR to do that?

sorry. i did, but forgot to comment about that approach. it doesnt seem to me like there is a clean approach there either that is maintainable and still accomplishes the goal for new breaking changes. our approach to true peer dependencies and node versions is to keep them open ended, so we would have to release a new version with updated ranges once we are aware that a new major version is incompatible, which also requires responding fairly quickly to be most helpful. each of the conventional-commits packages has its own individual major version (an approach that i agree with), so we would have to handle each one individually. this also means more investigation when trying to release a version for such incompatibility communication.

in the end, i think this almost entirely comes down to folks installing latest versions in pipelines without pinning a major version. would be open to suggestions to make this suggestion more clear and discoverable in docs or elsewhere in a general way that doesnt require maintainer action each time that breaking changes are released in conventional-commits packages.

[jedwards1211]

think this almost entirely comes down to folks installing latest versions in pipelines without pinning a major version.

In my case it wasn't that - I was installing conventional-changelog-conventionalcommits for the first time so that I could try to customize the behavior for a monorepo.

I can understand where you're coming from though. I can also understand the way all these different packages are structured. But - figuring out how to even customize everything and follow the control flow of release notes generation has left me thinking the work of fetching and parsing git commits and generating a changelog from them is spread out across too many packages for its own good. Maybe I would feel differently if these were all TS projects or the configuration was done via a strongly typed TS API rather than an unvalidated JSON DSL. It's pretty hairy to dig into how the configuration is getting passed around and used. And at least half of the code is for implementing that DSL that isn't really capable of doing what I want anyway, I wish I could just provide a function for filtering and categorizing commits by type and scope, etc, which would be way more flexible and require way less library code.

[DenisBalan]

We have the same issue..
Decided to downgrade for only package which is causing troubles to [email protected]

...
npm install semantic-release \
@semantic-release/changelog \
@semantic-release/git \
[email protected]
...

[anthony-nhs]

in the end, i think this almost entirely comes down to folks installing latest versions in pipelines without pinning a major version. would be open to suggestions to make this suggestion more clear and discoverable in docs or elsewhere in a general way that doesnt require maintainer action each time that breaking changes are released in conventional-commits packages.

I agree that is what people should do. However, the problem I found is that is currently hard to test if a major version bump will cause something to fail as we have semantic-release only running on our main branch. Implementing semantic-release/semantic-release#3278 would allow us to at least run with dry-run in a branch where we upgrade versions and see if anything breaks