Cannot find module 'conventional-changelog-conventionalcommits' using latest versions #2922
Comments
yes, your installation command installs the latest versions of all of those packages. the conventional-commits project released a major version of that package today that fails the tests within our projects in a similar way. see those failing PRs below:
since these versions were just released, we have not investigated. since it was a major version, breaking changes are expected, but the failure did not come from a problem with this project. rather you need to prevent your installation command from installing a version that is not compatible. if you would like to investigate what it would take to update our plugins to be compatible with the new version, we welcome the assistance. however, you could install with a major version defined to avoid this problem in your project for now - npm install -g semantic-release @semantic-release/gitlab @semantic-release/release-notes-generator @semantic-release/commit-analyzer conventional-changelog-conventionalcommits conventional-changelog-angular @semantic-release/exec @semantic-release/git
+ npm install -g semantic-release @semantic-release/gitlab @semantic-release/release-notes-generator @semantic-release/commit-analyzer conventional-changelog-conventionalcommits@6 conventional-changelog-angular @semantic-release/exec @semantic-release/git |
|
I don't know if this is related, but our pipelines began to fail silently couple days ago. There is no error, the last line is We are using currently the latest versions of the following:
|
With this I have a small problem. While I do agree that it would be best practice to use specific versions, it would be great that there would be some clear information on what version is supported and where. I don't know how tightly knit you are between different projects in semantic-release group and with |
Did you find a fix for that? Or is it still failing? |
Unfortunately I did not have time to test or debug it further. Our transition to semantic release built into our CI images has been slow, but luckily we already had it installed to it, including the plugins, so we simply removed the installation from our job so that it wouldn't use the latest but bit older ones. If I have time to test it more tomorrow or day after, I will post the results here. |
i'm not sure what to say here @XC-. you are installing that dependency directly; not through semantic-release. we provide as much of this sort of information as we can through our definitions through in the end, this is the role of semver. the package released a breaking change and communicated that fact through releasing a major version. if you are installing without considering that chance,
short of using a specific version, we do at least recommend installing a specific major to prevent updating past a breaking change unintentionally. you would still need to remember to update that declaration, but renovate can help with that, even with inline versions in your installation command. |
Started to experience the same issue as @XC- today in most of our pipelines that use semantic-release. Our setup is the following: .releaserc.json {
"plugins": [
[
"@semantic-release/commit-analyzer",
{
"preset": "eslint",
"releaseRules": [
{ "tag": "FIX", "release": "patch" },
{ "tag": "FEAT", "release": "minor" },
{ "tag": "UPDATE", "release": "minor" },
{ "tag": "UPGRADE", "release": "minor" },
{ "tag": "BREAKING", "release": "major" },
{ "tag": "DOCS", "release": "patch" },
{ "tag": "CHORE", "release": "minor" },
{ "tag": "BUILD", "release": "patch" },
{ "tag": "REFACTOR", "release": "minor" },
{ "tag": "TEST", "release": "patch" },
{ "tag": "CI", "release": "patch" },
{ "tag": "PERF", "release": "minor" }
]
}
],
[
"@semantic-release/release-notes-generator",
{
"preset": "eslint"
}
],
"@semantic-release/github"
]
}
Workflow file: - name: Semantic Release
uses: cycjimmy/semantic-release-action@v3
id: semantic
with:
extra_plugins: |
conventional-changelog-eslint
branches: |
[
'main',
{
name: 'alpha',
prerelease: true
},
{
name: 'beta',
prerelease: true
}
]
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Edit: I was able to fix the issues by setting: |
@travi What I'm trying to say here, that package.json might not be the first place people look for compatibility information. I do agree that this might not be the correct place to discuss about this, as But I do suspect that somewhere there is another issue on semantic-release's end, and that is the silent fail. In situations like this, I would expect an error, not a completely silent fail. There was no indication of error in the logs, the execution just ended suddenly. |
Same issue here, but using conventioanl-changelog-conventionalcommits instead of eslint. |
|
since we are seeing feedback about this issue in multiple locations, i've created a tracking issue to start to centralize the conversation. see #2929 |
Current behavior
Using GitLab CI, I run the following:
And I get this output:
Running the same code locally works fine.
Node version is 18.17.1
Expected behavior
Should run without an error
semantic-releaseversion21.1.1
CI environment
GitLab
Plugins used
@semantic-release/gitlab
@semantic-release/release-notes-generator
@semantic-release/commit-analyzer
conventional-changelog-conventionalcommits
conventional-changelog-angular
@semantic-release/exec
@semantic-release/git
semantic-releaseconfigurationCI logs
(stated above)
The text was updated successfully, but these errors were encountered: