nx release version does not propagate changes to release groups with "projectsRelationship": "independent"

[mpsanchis]

Current Behavior

In the following case:

G1 ({ "projectsRelationship": "independent" }):
- A
  -> depends on C
- B
G2 ({ "projectsRelationship": "fixed" }):
- C
- D

I would expect that, if C or D are modified, then A is bumped. Currently, A and B don't see any differences, and log something like:

A 🚫 No changes were detected using git history and the conventional commits standard

Expected Behavior

Changes are propagated to other projects/groups, no matter what's their projectsRelationship value

GitHub Repo

https://github.com/mpsanchis/nx-21-release

Steps to Reproduce

1. Clone repo in https://github.com/mpsanchis/nx-21-release
2. git checkout only-commons-syncd
3. npm i
4. npx nx release version

Note that the repository has several branches with different scenarios. This one corresponds to the following sketch:

Nx Report

NX   Report complete - copy this into the issue template

Node           : 18.20.8
OS             : darwin-arm64
Native Target  : aarch64-macos
npm            : 10.8.2

nx             : 21.2.0-beta.3
@nx/js         : 21.2.0-beta.3
@nx/workspace  : 21.2.0-beta.3
@nx/devkit     : 21.2.0-beta.3
---------------------------------------
Cache Usage: 0.00 B / 92.64 GB

Failure Logs

Package Manager Version

npm 10.8.2

Operating System

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

Additional Information

Opening issue in case it helps you guys to track. An MR with failing tests will follow.

[mpsanchis]

More details about the issue here:

The ReleaseGroupProcessor has a propagateChanges(toGroup, fromGroup) function that essentially does (pseudocode):

function propagateChanges(toGroup, fromGroup) {
	const updateDependents = fromGroup.updateDependents === "auto";
	if (!updateDependents)
		toGroup.getLogger().buffer(`skipping dependency updates for ${toGroup}`);

	let groupBumped = false;
	let bumpType = "none";

	if (toGroup.projectsRelationship === "fixed") {
		// For fixed groups, we only need to check one project
		const project = toGroup.projects.getFirst();
		if (project.dependentProjects.some(p => fromGroup.projects.has(p))) {
			bumpType = "patch";
			groupBumped = true;
	  }
	}
	if (groupBumped) {
		for (const p of toGroup.projects) {
			bumpVersionForProject(p, bumpType, "DEPENDENCY_ACROSS_GROUPS_WAS_BUMPED");
		}
	}
}

Note that if toGroup.projectsRelationship === "independent", then groupBumped = false, and nothing happens to toGroup.

[JamesHenry]

@mpsanchis and I are discussing this, assigned myself

[Johncw10]

@mpsanchis and I are discussing this, assigned myself

@JamesHenry / @mpsanchis any update on this issue? Current behaviour requires a dummy commit pushed to the app in order to force a release - which can be quite tedious if missed, if you rely on nx release to generate release versions

Thanks a lot in advance!!

[mpsanchis]

@Johncw10 I'm not part of the Nx team, just a user like you. However, here's a tip:

1. Upgrade to latest Nx, as James and I have modified some stuff
2. (Personal advice, not nx-related): use only "projectsRelationship": "fixed", and ditch the independent groups completely. If needed to separate a project, make another release group with fixed relationship just for it. I think being able to add independent groups can be nice in some situations, but adds complexity. Not sure about your use case, but the (many) repos I am managing now have only fixed relationships :)

Cheers

[Johncw10]

@mpsanchis sorry I mistook your role - massive thanks for your support in any case!

Upgrading is definitely ongoing.

My use case:

• independent apps, versioned distinctly (app-A@1.0.0, app-B@2.0.0)
• each app rarely changes code-wise itself, but more often the libraries they depend on change
• I use conventional commits fully to manage version intentions - I.e. a change which adds a 'feat: ...' commit with code changes to app-A should bump app-A's version, and ideally not app-B
• more awkwardly, updates to libraries (not apps) which app-A or app-B depend on are also made with conventional commits - and ideally should propagate version updates as needed to app-A and app-B (dependent on whether they impact or 'affect' that app)

It's quite a tricky landscape, with release groups/relationships/conventional commits/affected changes

But I think if the options could align, it would be a real game changer for nx releasing :)

I understand if this setup is not feasible with the options available today, particularly the focus that independent versioning together with conventional commits has (where it focuses on the file changes to that app alone - instead of the 'affected' dependent updates made in conventional commits to other libraries)

Thanks again, keen to know if there's anything I'm missing!

[JamesHenry]

FYI in nx 22 this behaviour is changing to align more with affected (which takes things like implicit dependencies into account): #32915

[JamesHenry]

Hi Folks, Nx 22 has been released so I'm going to close this one: https://nx.dev/blog/nx-22-release#enhanced-release-workflows

For any specific issues with Nx 22's new default of updateDependents: always please create a fresh issue with full context/repro etc

Thanks!

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.