Cross-release-group dependency leads to error: Version data key "project-name" already exists in version data

[mpsanchis]

Current Behavior

Hi folks!

Reporting as suggested in the error message:

Version data key "project-name" already exists in version data. 
This is likely a bug, please report your use-case on https://github.com/nrwl/nx

I am exploring the new functionality that updates dependents: #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 to auto, 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:

flowchart TB
    internal-lib-->common-lib
    subgraph G1
    common-lib
    common-but-unused
    end
    subgraph G2
    app1-->internal-lib
    app2
    end

Loading

Expected Behavior

When a project from release group G2 depends on a project from G1, the version calculator should take it into consideration, and bump whatever is highest, among:
a. The "indirect" bump due to the dependency to G2 (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 in G2 if there have been changes

Some examples to illustrate the expected behavior (assuming conventional commits):

• In a PR that only modifies the common lib in G1, I'd expect that projects in G2 are bumped. Moreover, I'd expect that if G2 does not release independently, that even other projects in G2 that do not depend on G1 (such as app2) get the same bump.
• In a PR that modifies both G1 and G2, and where there is a feat! commit for G2, I'd expect that projects in G2 are bumped with a major increase.
• I'd expect that projects in G2 are bumped with a minor increase (because minor = max(minor, patch)), if
  • (i.) there is a way to determine the bump caused by a change in dependencies (see (a.) above),
  • (ii.) that bump is set to minor and
  • (iii.) there is a PR that modifies both G1 and G2, with a fix commit in G2
• If we consider the previous case, but with G2 releasing independently, then I'd expect that the logic above applies to the projects that depend on common-lib (app1, internal-lib), but other projects such as app2 should only be bumped according to the changes made to it and the commit messages (not considering "indirect" bumps, since there is no relationship to G1).
• In a PR that modifies common-but-unused and where G1 is released independently, I'd expect a version bump to be made only to common-but-unused
• In a PR that modifies common-but-unused OR common-lib, and where G2 is released all together, I'd expect a version bump to be made to G1, but also to the projects of G2 that depend on common-lib (and potentially all G2, if it is also released together)

GitHub Repo

No response

Steps to Reproduce

1. Generate a repo with dependencies, and separate the dependencies into two release groups. The nx.json looks like this

  "release": {
    "changelog": {
      "workspaceChangelog": false
    },
    "version": {
      "generatorOptions": {
        "updateDependents": "auto"
      },
      "conventionalCommits": true,
      "git": {
        "commit": false,
        "stageChanges": false,
        "tag": false
      }
    },
    "groups": {
      "g1": {
        "projects": ["common-lib", "common-but-unused"],
        "releaseTagPattern": "g1@{version}",
        "version": {
          "generatorOptions": {
            "updateDependents": "auto"
          }
        },
        "projectsRelationship": "independent"
      },
      "g2": {
        "projects": ["app1", "internal-lib", "app2"],
        "releaseTagPattern": "g2@{version}"
      }
    }

2. Run something like npx nx release version --dry-run --verbose

Nx Report

Node   : 18.18.2
OS     : darwin-arm64
pnpm   : 8.10.0

nx                 : 19.1.0
@nx/js             : 19.1.0
@nx/jest           : 19.1.0
@nx/linter         : 19.1.0
@nx/eslint         : 19.1.0
@nx/workspace      : 19.1.0
@nx/devkit         : 19.1.0
@nrwl/devkit       : 18.3.3
@nx/eslint-plugin  : 19.1.0
@nx/playwright     : 19.1.0
@nx/plugin         : 19.1.0
@nx/react          : 19.1.0
@nrwl/tao          : 19.1.0
@nx/vite           : 19.1.0
@nx/web            : 19.1.0
typescript         : 5.4.2
---------------------------------------
Community plugins:
@jnxplus/nx-maven      : 0.42.1
@monodon/rust          : 1.4.0
@ngx/deploy-npm        : 7.1.0
@nx-go/nx-go           : 3.0.0
@nx-tools/nx-container : 5.2.0

Failure Logs

Version data key "project-name" already exists in version data. This is likely a bug, please report your use-case on https://github.com/nrwl/nx

Package Manager Version

8.10.0

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

No response

[kumboleijo]

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

[kumboleijo]

Any news here? I'm still able to reproduce this with the latest version of nx.

 NX   Report complete - copy this into the issue template

Node           : 20.18.1
OS             : darwin-arm64
Native Target  : aarch64-macos
pnpm           : 8.15.1

nx             : 20.1.4
@nx/js         : 20.1.4
@nx/jest       : 20.1.4
@nx/eslint     : 20.1.4
@nx/workspace  : 20.1.4
@nx/devkit     : 20.1.4
@nx/node       : 20.1.4
typescript     : 5.5.2

[triglian]

We're also interested in a fix for this.

[kumboleijo]

I could address this question within a live session on YT a couple of weeks ago (https://www.youtube.com/live/tui0sTvfi64?si=2Ap2kXVyp0nYDqjc&t=8463) - basically @JamesHenry said that there is currently a bigger refactoring / rewriting going on which will solve this issue.

TL;DR;

• currently not supported
• should be available as opt-in in nx@21

[jyannessa-mtx]

We're also unable to publish some of our packages due to this bug with { "updateDependents": "auto" }

Effected versions from 19.6.5 to latest 20.4.0

[JamesHenry]

I’ve finally been able to revisit this and will have an opt-in new implementation of versioning available ASAP

[JamesHenry]

I'm pleased to say that this is resolved in the rewritten implementation of versioning: #30418