You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NX release updateDependants doesn't properly propagate version update through package.json, and package depends on the older version which breaks npm install
Expected Behavior
Version is properly propagated to all dependent projects
the last commit on branch is release commit (npx nx release)
run npm install --force
observe error npm error 404 '@zoran995/[email protected]' is not in this registry., which is valid error thrown by npm as the version of settings-shared in workspace is bumped to 0.1.0, but if we check settings-users and settings-main it references settings-shared version of 0.0.1. The same happens for settings-users reference in settings-main but it is more confusing as it references version 0.0.3 which never existed
p.s. you can remove the last commit and run it again to get a fresh state
Nx Report
NX Report complete - copy this into the issue template
When I tried to debug the this it always showed that there are circularDependencies but it seems that it marks everything as a circular dependency.
Another things I observed is that in first pass it will properly resolve all dependent packages, but later it seems it bumped their version and then version check fails and it doesn't update that package because of that, i.e. package has version 0.0.1 but due to update of another package it version got bumped to 0.0.2 or 0.1.0 during release process and it no longer satisfies the version range of 0.0.1 and it doesn't get updated.
The text was updated successfully, but these errors were encountered:
This has similar symptoms to a bug we have been seeing, when you set release.version.generatorOptions.updateDependents to never the versions will resolve correctly, but then you have an issue of components that only have version bumps not getting their own release.
Something in the code for bumping versions based on dependents overrides conventional commit versioning from earlier in the version process.
This behaviour was fixed in our implementation in a recent version update, can't remember off the top of my head which one unfortunately but it was in version 20.
I've tested with the latest version (20.2.2) and I still get this issue.
At least when using --first-release or "version.generatorOptions.fallbackCurrentVersionResolver": "disk"
Current Behavior
NX release updateDependants doesn't properly propagate version update through
package.json
, and package depends on the older version which breaks npm installExpected Behavior
Version is properly propagated to all dependent projects
GitHub Repo
https://github.com/zoran995/nx-release-reproduction
Steps to Reproduce
npx nx release
)npm install --force
npm error 404 '@zoran995/[email protected]' is not in this registry.
, which is valid error thrown by npm as the version ofsettings-shared
in workspace is bumped to0.1.0
, but if we checksettings-users
andsettings-main
it referencessettings-shared
version of 0.0.1. The same happens forsettings-users
reference insettings-main
but it is more confusing as it references version0.0.3
which never existedp.s. you can remove the last commit and run it again to get a fresh state
Nx Report
NX Report complete - copy this into the issue template
Node : 20.17.0
OS : darwin-arm64
Native Target : aarch64-macos
npm : 10.8.2
nx : 20.0.0
@nx/js : 20.0.0
@nx/jest : 20.0.0
@nx/eslint : 20.0.0
@nx/workspace : 20.0.0
@nx/devkit : 20.0.0
@nx/eslint-plugin : 20.0.0
@nx/react : 20.0.0
@nx/rollup : 20.0.0
@nx/vite : 20.0.0
@nx/web : 20.0.0
@nx/webpack : 20.0.0
typescript : 5.5.4
Registered Plugins:
@nx/webpack/plugin
@nx/eslint/plugin
@nx/jest/plugin
@nx/rollup/plugin
@nx/vite/plugin
Failure Logs
No response
Package Manager Version
No response
Operating System
Additional Information
When I tried to debug the this it always showed that there are
circularDependencies
but it seems that it marks everything as a circular dependency.Another things I observed is that in first pass it will properly resolve all dependent packages, but later it seems it bumped their version and then version check fails and it doesn't update that package because of that, i.e. package has version 0.0.1 but due to update of another package it version got bumped to 0.0.2 or 0.1.0 during release process and it no longer satisfies the version range of 0.0.1 and it doesn't get updated.
The text was updated successfully, but these errors were encountered: