Closed effektsvk closed 3 weeks ago
Same thing here :(
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?
same this here
@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
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.0conventional-changelog-conventionalcommits
v7.0.2I 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.
@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
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
We have a custom package that uses a few semantic-release plugins (
commit-analyzer
,slack-bot
,changelog
,npm
,github
andgit
), 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?
then
@commitlint/config-conventional
has to upgradeconventional-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 toyarn 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.
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:
@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:
@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 😅
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
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: