semantic-release fails due to a crash in `conventional-changelog-writer` after updating to latest major versions

[effektsvk]

Hello,

we're having a problem with semantic-release command, our release workflow fails.

I have a suspicion that it's related to issue #633. I didn't want to bump the issue though, because I'm not sure if the culprit is the same.

Here is our failed workflow, but I think this excerpt is enough:

[7:00:51 AM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[7:00:51 AM] [semantic-release] › ℹ  The next release version is 2.0.9
[7:00:51 AM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[7:00:51 AM] [semantic-release] › ✘  Failed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[7:00:51 AM] [semantic-release] › ✘  An error occurred while running semantic-release: TypeError: Method Date.prototype.toString called on incompatible receiver [object Date]
    at Proxy.toString (<anonymous>)
    at [Symbol.toPrimitive] (<anonymous>)
    at new Date (<anonymous>)
    at Object.formatDate (file:///home/runner/work/semantic-release/semantic-release/node_modules/conventional-changelog-writer/dist/utils.js:8:12)
    at defaultCommitTransform (file:///home/runner/work/semantic-release/semantic-release/node_modules/conventional-changelog-writer/dist/options.js:23:23)
    at transformCommit (file:///home/runner/work/semantic-release/semantic-release/node_modules/conventional-changelog-writer/dist/commit.js:29:23)
    at write (file:///home/runner/work/semantic-release/semantic-release/node_modules/conventional-changelog-writer/dist/writers.js:39:28)
    at async nextAsync (node:internal/streams/from:182:33) {
  pluginName: '@semantic-release/release-notes-generator'
}
TypeError: Method Date.prototype.toString called on incompatible receiver [object Date]
    at Proxy.toString (<anonymous>)
    at [Symbol.toPrimitive] (<anonymous>)
    at new Date (<anonymous>)
    at Object.formatDate (file:///home/runner/work/semantic-release/semantic-release/node_modules/conventional-changelog-writer/dist/utils.js:8:12)
    at defaultCommitTransform (file:///home/runner/work/semantic-release/semantic-release/node_modules/conventional-changelog-writer/dist/options.js:23:23)
    at transformCommit (file:///home/runner/work/semantic-release/semantic-release/node_modules/conventional-changelog-writer/dist/commit.js:29:23)
    at write (file:///home/runner/work/semantic-release/semantic-release/node_modules/conventional-changelog-writer/dist/writers.js:39:28)
    at async nextAsync (node:internal/streams/from:182:33) {
  pluginName: '@semantic-release/release-notes-generator'
}error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

[felixb-croesus]

Same thing here :(

[travi]

I haven't seen this in my own projects. We need more details to understand what is unique in your projects. Could you give details like versions of anything semantic-release that you've installed directly? Extra plugins? Conventional-changelog presets?

[MHDFahz]

same this here

[effektsvk]

@travi We have a custom package that uses a few semantic-release plugins (commit-analyzer, slack-bot, changelog, npm, github and git), but the error seems to be specifically with @semantic-release/release-notes-generator.

We are using conventionalcommits preset for that plugin as you can see here:
https://github.com/technology-studio/semantic-release/blob/main/src/index.js

[fin-gal]

I was getting the same error here and solved it by unpinning the conventional-changelog-conventionalcommits plugin.

Runing this was giving me an error:

• semantic-release v24.0.0
• conventional-changelog-conventionalcommits v7.0.2

I was using the pinned version of 7.0.2 because it was the temporary fix to issue #633

However, unpinning conventional-changelog-conventionalcommits solved the problem, so running:

• semantic-release unpinned (v24.0.0)
• conventional-changelog-conventionalcommits unpinned (v8.0.0 I suppose, i am not printing it out in my logs).

I didn't test it but I assume that rolling back semantic-release to the latest version before 24.0.0 and using conventionalchangelog 7.0.2 will work also as that is what was functional before for me.

[effektsvk]

@fin-gal I see, but then @commitlint/config-conventional has to upgrade conventional-changelog-conventionalcommits to v8. Currently it uses v7.0.2, so that's why that specific version is installed, at least in my project according to yarn why.

There is an "ongoing" PR, not sure if that's a fair name, since it looks like it's stuck for a month 😅
conventional-changelog/commitlint#4069

[travi]

unpinning conventional-changelog-conventionalcommits solved the problem,

please reconsider unpinning. instead, we recommend pinning the current major version now that you have verified that it is working. pinning the current major versions will help you avoid surprises the next time that breaking changes are released

[travi]

We have a custom package that uses a few semantic-release plugins (commit-analyzer, slack-bot, changelog, npm, github and git), but the error seems to be specifically with @semantic-release/release-notes-generator.

We are using conventionalcommits preset for that plugin as you can see here: technology-studio/semantic-release@main/src/index.js

there is a typo in your config (preset vs present) at https://github.com/technology-studio/semantic-release/blob/ddaa60038814f92faf4b5ba17354f1c45aedb11e/src/index.js#L10

also, what does npm ls conventional-changelog-conventionalcommits give you? do you have multiple versions installed somehow?

[travi]

then @commitlint/config-conventional has to upgrade conventional-changelog-conventionalcommits to v8. Currently it uses v7.0.2, so that's why that specific version is installed, at least in my project according to yarn why.

it is interesting to me that this sort of conflict pretty consistently gets reported for projects using yarn. i have not seen this reported for npm-based projects. if conventional-changelog-conventionalcommits is directly installed, the package manager should be installing that version as the higher precedence than the one installed as a transitive dependency of commitlint.

regardless, if you are experiencing a conflict, you still have the option to pin the previous major versions until commitlint finishes the update.

[sheerlox]

I can reproduce this on npm & node 22.2.0.

semantic-release versions:

"semantic-release": "24.0.0",
"@semantic-release/release-notes-generator": "14.0.0",

output of npm ls conventional-changelog-conventionalcommits (I'm using a custom preset):

└─┬ @insurgent/conventional-changelog-preset@9.0.1
  └── conventional-changelog-conventionalcommits@7.0.2

I'm looking into it!

EDIT: my bad, I didn't read v14's changelog, everything (not) working as expected 😅

[sheerlox]

@effektsvk since you're referencing conventional-changelog-conventionalcommits from your semantic-release preset, it should be listed in your dependencies on this project.

Because it is not explicitly listed, it's probably using a version "accidentally" installed alongside it (probably from @txo/commitlint).

Although a bit different from your setup, I have a custom conventional-changelog preset and a custom commitlint config based on an older version of the former (because commitlint does not ESM yet).

I just updated the conventional-changelog preset to align with the new interface released in v8, and I now have two different versions of conventional-changelog-conventionalcommits, which doesn't seem to be an issue:

some-secret-project@2.7.4 /home/sherlox/workspace/some-secret-project
├─┬ @insurgent/commitlint-config@19.0.0
│ └─┬ @insurgent/conventional-changelog-preset@8.0.2
│   └── conventional-changelog-conventionalcommits@7.0.2
└─┬ @insurgent/conventional-changelog-preset@10.0.0
  └── conventional-changelog-conventionalcommits@8.0.0

tl;dr adding "conventional-changelog-conventionalcommits": "^8.0.0", to your package.json will solve the issue.

Please confirm if that does the trick for you 😄

[effektsvk]

@sheerlox, @travi Sorry, I just now noticed the replies, for some reason I didn't get any email.

We intentionally install all commitlint related packages only in @txo/commitlint. This makes it easier to find and update packages.

According to yarn why, we have conventional-changelog-conventionalcommits on version 7.0.2, and it's installed because of @commitlint/config-conventional. I can install the v8.0.0 but I'd rather avoid having two different versions installed, so probably the best solution is to wait until conventional-changelog/commitlint#4069 is merged so it can be then updated in @txo/commitlint.

$ yarn why conventional-changelog-conventionalcommits
...
=> Found "conventional-changelog-conventionalcommits@7.0.2"
info Reasons this module exists
   - "@commitlint#config-conventional" depends on it
   - Hoisted from "@commitlint#config-conventional#conventional-changelog-conventionalcommits"
...

Also, @travi, thank you for catching that typo 😅

[travi]

closing because it sounds like there are known solution options for all scenarios mentioned in this thread. please feel free to comment if you believe there is still an unhandled scenario.

to summarize, either

• update pinned versions of conventional-changelog packages to the latest major versions if you have updated to semantic-release v24. for the conventionalcommits preset, the major to update to is v8
• pin semantic-release to v23 if you want or need to continue using an older version of the conventional-changelog plugins, such as if you have a conflict with a version installed with commitlint and dont want to locally install the preset package to override the transitive commitlint dependency