Deleting or renaming a project causes every project to be released + versioned

[comp615]

Current Behavior

Currently, in the affected logic there is a check that if any change touches a package.json file, and that file does not exist (at runtime), then every package is treated as affected. With the new versioning coupled to affected logic, this in turn causes every package to be released with the default release message.

This is confusing to consumer and platform teams alike, and causes a huge amount of work when doing what seem like smaller refactors in the repo.

Expected Behavior

I'm omnibussing this ticket a bit, but feel free to split it up if these are separate concerns or solves:

1. Deleting / renaming a package should not affect the entire repo. This seems like it might exist because plugins could have undefined behavior on creating nodes and so on. But if that's the case, there might need to be a stricter contract (i.e. my plugin only makes nodes on the project itself / declare as isolate)
2. The detection of this should rely on the given base + head params, not the runtime existance of the file. This creates confusing scenarios when comparing seemingly unrelated diffs (maybe necessary, but ideally a note!)
3. The default release reason messages should be more detailed (i.e. bumped because an unrelated package in the repo was renamed)...I'd settle for an ENUM mapped from the 6 or so affected detectors

This was a version bump only for {project-name} to align it with other projects, there were no code changes. is the default, but that makes it sound like it was written for the lock-step versioning method only. It covers up a seeming number of other reasons this happens!

GitHub Repo

No response

Steps to Reproduce

1. In any NX repo, simply rename a folder (e.g. libs/package-a -> libs/package-a-v2)
2. run nx show projects --affected

Nx Report

NX   Report complete - copy this into the issue template

Node           : 20.19.1
OS             : darwin-arm64
Native Target  : aarch64-macos
pnpm           : 10.18.3

nx                     : 22.0.1
@nx/js                 : 21.1.2
@nx/jest               : 22.0.1
@nx/eslint             : 22.0.1
@nx/workspace          : 22.0.1
@nx/cypress            : 22.0.1
@nx/devkit             : 22.0.1
@nx/eslint-plugin      : 22.0.1
@nx/module-federation  : 22.0.1
@nx/plugin             : 22.0.1
@nx/react              : 22.0.1
@nx/rollup             : 22.0.1
@nx/storybook          : 22.0.1
@nx/vite               : 22.0.1
@nx/web                : 22.0.1
typescript             : 5.5.4

---------------------------------------
Nx key licensed packages
Licensed to Block Inc..

@nx/powerpack-s3-cache  : 4.0.0

---------------------------------------
Registered Plugins:
@nx/vite/plugin
@squareup/service-dashboard-web-runtime/nx-plugin
@nx/storybook/plugin
@squareup/nx-lint-plugin
@squareup/nx-stats-plugin
@squareup/service-i18n/nx-plugin
@squareup/infra-e2e-playwright/nx-plugin
---------------------------------------
Community plugins:
@squareup/infra-e2e-playwright : 0.0.0
@squareup/service-i18n         : 0.101.1
---------------------------------------
Local workspace plugins:
@squareup/infra-e2e-playwright
@squareup/service-i18n
@squareup/migrate
---------------------------------------
Cache Usage: 0.00 B / 92.64 GB
---------------------------------------
The following packages should match the installed version of nx
  - @nx/js@21.1.2

To fix this, run `nx migrate nx@22.0.1`
---------------------------------------

Failure Logs

Package Manager Version

No response

Operating System

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

Additional Information

No response

[laneysmith]

To add a little more detail about where we saw this: we noticed that releaseVersion was patch bumping a lot of projects unexpectedly. For those projects, getCommitsRelevantToProjects included a chore(release): … commit that only updated a couple unrelated projects' package.json#versions and changelogs. By filtering out touched files for that commit, we narrowed it down to the file changes in a project that had since been deleted in a newer commit, which was hitting this code path and affecting all projects.

So in addition to the issue described above, it also surprised me that getCommitsRelevantToProjects would include release commits, which seems like a separate bug to me as well.