Open mpsanchis opened 4 months ago
I can confirm, that I currently stumble into the same issue with the following versions of nx
:
❯ nx report
NX Report complete - copy this into the issue template
Node : 20.13.1
OS : darwin-arm64
pnpm : 9.4.0
nx (global) : 19.3.1
nx : 19.3.2
@nx/js : 19.3.2
@nx/eslint : 19.3.2
@nx/devkit : 19.3.2
@nx/node : 19.3.2
---------------------------------------
Community plugins:
@nx-tools/nx-container : 6.0.1
My group setup looks like this:
Running nx release
("updateDependents": "auto"
) with changes on my lib
in Group A
results in Error: Version data key "api" already exists in version data. This is likely a bug, please report your use-case on https://github.com/nrwl/nx
Current Behavior
Hi folks!
Reporting as suggested in the error message:
I am exploring the new functionality that updates dependents: https://github.com/nrwl/nx/pull/23252, to see if it covers other cases apart from releasing projects independently. I have two groups: one (G1) with common libs, and another (G2) with other components that use the common libs. G1 now includes the option
updateDependents
set toauto
, so it bumps the versions of its dependencies (which live in G2).When running
nx release version
, G1 is first versioned, and then the versionResult object for G1 contains already versions for projects in G2. Therefore, when G2 is versioned,appendVersionData
crashes, as it does not expect projects in G2 to already have a version.This sketch in a comment in #23252 shows my setup. I will replicate it here for clarity:
Expected Behavior
When a project from release group
G2
depends on a project fromG1
, the version calculator should take it into consideration, and bump whatever is highest, among: a. The "indirect" bump due to the dependency toG2
(by the way: it was mentioned in #23252 that "you can control what kind of semver bump should be applied" - how can this be configured? I could only find a comment that says that the bump is of type patch) b. The potential bump inG2
if there have been changesSome examples to illustrate the expected behavior (assuming conventional commits):
G1
, I'd expect that projects inG2
are bumped. Moreover, I'd expect that ifG2
does not release independently, that even other projects inG2
that do not depend onG1
(such asapp2
) get the same bump.G1
andG2
, and where there is afeat!
commit forG2
, I'd expect that projects inG2
are bumped with a major increase.G2
are bumped with a minor increase (becauseminor = max(minor, patch)
), ifminor
andG1
andG2
, with afix
commit inG2
G2
releasing independently, then I'd expect that the logic above applies to the projects that depend oncommon-lib
(app1
,internal-lib
), but other projects such asapp2
should only be bumped according to the changes made to it and the commit messages (not considering "indirect" bumps, since there is no relationship toG1
).common-but-unused
and whereG1
is released independently, I'd expect a version bump to be made only tocommon-but-unused
common-but-unused
ORcommon-lib
, and whereG2
is released all together, I'd expect a version bump to be made toG1
, but also to the projects ofG2
that depend oncommon-lib
(and potentially allG2
, if it is also released together)GitHub Repo
No response
Steps to Reproduce
Generate a repo with dependencies, and separate the dependencies into two release groups. The
nx.json
looks like thisRun something like
npx nx release version --dry-run --verbose
Nx Report
Failure Logs
Package Manager Version
8.10.0
Operating System
Additional Information
No response