feat(release): updateDependents generator option for versioning, support circular dependencies

[JamesHenry]

Current Behavior

When releasing projects independently, if a dependent project is untouched directly by the changes, it will not have its version updated and there is no way to opt into this behavior.

Additionally, circular dependencies between packages are not supported.

Expected Behavior

When releasing projects independently, if a dependent project is untouched directly by the changes, BY DEFAULT it will not have its version updated, BUT you can opt into it always being updated via a generator option (release.version.generatorOptions.updateDependents = auto and you can control what kind of semver bump should be applied to the otherwise unchanged dependent project. Transitive local dependents (A -> B -> C) will also be updated in this scenario.

Additionally, when opted into, such version only changes will appear in the changelog under a new Updated Dependencies section.

Circular dependencies between packages are now supported for versioning, changelog generation and publishing.

Related Issue(s)

Fixes #22268

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Updated (UTC)
nx-dev	⬜️ Ignored (Inspect)	Visit Preview	May 21, 2024 0:34am

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 20ef78e. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 6 targets

• nx affected --targets=e2e,e2e-ci --base=65e6727bdc46de771cdd36996a79d643b7a04364 --head=20ef78e05899700b19f8e0d8603e08ae3e4a02f5 --parallel=1
• nx run-many -t check-imports check-commit check-lock-files check-codeowners documentation --parallel=1 --no-dte
• nx affected --targets=lint,test,build --base=65e6727bdc46de771cdd36996a79d643b7a04364 --head=20ef78e05899700b19f8e0d8603e08ae3e4a02f5 --parallel=3
• nx-cloud record -- nx format:check --base=65e6727bdc46de771cdd36996a79d643b7a04364 --head=20ef78e05899700b19f8e0d8603e08ae3e4a02f5
• nx documentation --no-dte
• nx affected -t e2e-macos-ci --parallel=1 --base=65e6727bdc46de771cdd36996a79d643b7a04364 --head=20ef78e05899700b19f8e0d8603e08ae3e4a02f5

---

Sent with 💌 from NxCloud.

[FrozenPandaz]

Ensure this does not happen when the versioning is fixed rather than independent

[JamesHenry]

I added e2e coverage for all the combinations of fixed vs independent:
3350b72

That additionally led me to discover that we did not previously allow cycles for publishing at all, so this PR now officially adds support for circular dependencies across versioning, changelog generation and publishing.

I have updated the PR title and description accordingly

[JamesHenry]

@FrozenPandaz Please take another look when you get chance, I think this should be good to go

[diosif-cr]

@JamesHenry I've been following this bit of work and how much you've done for it, and wanted to say thank you and that I'm extremely grateful. This makes Nx feature complete for a few of our projects, without any other 3rd party plug-ins.

[mpsanchis]

@JamesHenry Also my thank you in advance for the effort. I am looking forward to this feature 🙏

Here's two quick questions for the MR, if I may:

1. I have seen that you declare projectToDependencyBumps at the top of the release-version executor, and then in line 376 it is checking if (projectToDependencyBumps.has(projectName)) (in the case conventional-commits). However, if I understand correctly, the Map will not be filled with data until line 651, where the first .set() is called on it. Won't the Map be empty in line 376?

2. From the results of my manual tests, the behavior that you are adding is not only missing "When releasing projects independently", but in any scenario. I have seen repos where there is one release group (G1) containing shared libs, and then other release groups that contain apps that use those shared libs. If there is a change to G1, I'd expect that apps that belong to other groups "Gx" are also bumped. In this case, there would be no independent releasing, but this behavior would also be expected. Your change in the doesn't seem to apply only when "independent" is set, but I just wanted to double check.

[JamesHenry]

@mpsanchis

1. I don't think you have taken the loop into account
2. It is out of scope for this PR to change the relationships between groups

Please open/use and existing discussion or issue to discuss any specific concerns around how groups relate to one another

[jbadeau]

Also watching this MR as we need it to be able to release our repos which have cross release group dependencies

graph TD
    subgraph Todo Group
        A[Todo App] --> B[Todo Lib]
    end
    subgraph Shared Group
        B --> C[Shared Lib]
    end

If I change a project in Shared Group then I would expect a bump in some or all of the Todo Group projects depending on if the projects are released independently or not.

[JamesHenry]

@jbadeau See my previous comment, this PR is not the place for a discussion around changing how groups relate to one another

[mpsanchis]

If any others have the same doubt that I had: it's the topological ordering of the projects that ensures that the first projects in the for loop don't have any dependencies, and then the projectToDependencyBumps gets filled as the iterations progress. So projects that depend on other projects appear after in the loop, and the map already contains their information.

[rcolwell-cb]

This option doesn't seem to produce any change in behavior for me.
{
"defaultBase": "no-lerna",
"release": {
"version": {
"generatorOptions": {
"updateDependents": "auto"
},
"conventionalCommits": true
},
"projectsRelationship": "independent",
"projects": [
"packages//"
],
"releaseTagPattern": "{projectName}@{version}",
"changelog": {
"projectChangelogs": true
}
}
}

This is a project where lerna previously was used and attempting to transition everything to nx. When I make a change to a library project, none of the other library projects are getting version bumped, just their dependency updated.

I'm on 19.1.0-beta5, no global nx just project install.

[diosif-cr]

@rcolwell-cb I'm seeing the same result, and after stepping through the code, it looks like dependencies are only linked through the package.json: if project-a/package.json's dependencies includes project-b, the version is bumped accordingly. If you use implicitDependencies or just imports from project-b, version bumps won't happen together.

In our project, we're using implicitDependencies to link things together.

@JamesHenry is my understanding correct? Is only the package.json used for this new functionality?

[rcolwell-cb]

it's working for me now actually - still testing it with different scenarios of bumps. My nx wasn't updated after switching to beta so cleared some things and reinstalled...

[rcolwell-cb]

After testing it, there is definitely some weird logic I cannot understand. In some cases it's properly updating dependencies and package, but there are packages that get their dependencies updated but the package isn't getting updated.

Example, I am updating a button. Package name "@org/button"...
package: @org/date-picker has @org/button in its dependencies.
package: @org/modal also has @org/button in its dependencies.

@org/date-picker gets the updated dependency version of @org/button, but its version IS NOT bumped/no changelog.
@org/modal also gets updated dependency version of @org/button, and seemingly correctly - bumps version and get changelog.

Both these said packages also import these packages in code, in case the logic for the graph is formed from some intelligent process instead of package.json'.

I want to be sure my config isn't missing anything before I create an issue for this

[JamesHenry]

Please kindly don’t comment on closed issues or PRs. Please open a fresh issue that is specific to your circumstances and provide steps to reproduce, feel free to tag me