semantic-release / release-notes-generator

:clipboard: semantic-release plugin to generate changelog content with conventional-changelog
MIT License
298 stars 47 forks source link

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

Closed effektsvk closed 3 weeks ago

effektsvk commented 4 weeks ago

Hello,

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

I have a suspicion that it's related to issue https://github.com/semantic-release/release-notes-generator/issues/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 commented 4 weeks ago

Same thing here :(

travi commented 4 weeks ago

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 commented 4 weeks ago

same this here

effektsvk commented 4 weeks ago

@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 commented 4 weeks ago

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

Runing this was giving me an error:

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:

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 commented 4 weeks ago

@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 😅 https://github.com/conventional-changelog/commitlint/pull/4069

travi commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 3 weeks ago

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 :sweat_smile:

sheerlox commented 3 weeks ago

@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 :smile:

effektsvk commented 3 weeks ago

@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 https://github.com/conventional-changelog/commitlint/pull/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 commented 3 weeks ago

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