Convential commits release version now requires specific scope

[evanmwillhite]

Current Behavior

We use Nx as a monorepo tooling for a component library with independent project relationships. To get nx release to version a breaking change, the scope has to be very specific since upgrading from v20. feat!: ... and feat(@package/name)!: ... both work, but we prefer a different convention for scope.

Expected Behavior

feat(whatever)!: ... would trigger a breaking change.

It's noteworthy too that the CHANGELOG.md updates still correctly show the breaking change, so it appears to be something specific to the versioning logic.

Could the scope be more flexible again?

I can't share our repo, but let me know if you have any questions.

GitHub Repo

No response

Steps to Reproduce

1. Within an independent relationship library using Nx release and conventional commits, try commiting feat(random)!: ... after making a change to a project
2. Run npx nx release --dry-run and verify the commit did not make a breaking change

Nx Report

Node           : 20.19.0
OS             : darwin-arm64
Native Target  : aarch64-macos
pnpm           : 10.23.0

nx (global)        : 22.0.2
nx                 : 22.1.3
@nx/js             : 22.1.3
@nx/jest           : 22.1.3
@nx/eslint         : 22.1.3
@nx/devkit         : 22.1.3
@nx/eslint-plugin  : 22.1.3
@nx/plugin         : 22.1.3
typescript         : 5.6.3
---------------------------------------
Local workspace plugins:
automate
---------------------------------------
Cache Usage: 7.26 MB / 92.64 GB
---------------------------------------
⚠️ Multiple Nx versions detected

Your workspace uses nx@22.1.3, but other packages depend on a different version:
  - automate → @nx/devkit → nx@22.0.2

These packages should not have nx as a dependency. Please report this issue to the package maintainers.
Run `pnpm why nx@22.0.2` for more details.

Failure Logs

Package Manager Version

No response

Operating System

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

Additional Information

No response

[cogwirrel]

We’re seeing something similar in our repo, where feat(xxx): yyy creates a patch version bump where we’d expect a minor version, eg: https://github.com/awslabs/nx-plugin-for-aws/releases/tag/v0.62.1

feat: yyy creates a minor version bump as expected https://github.com/awslabs/nx-plugin-for-aws/releases/tag/v0.62.0

This started happening after our upgrade to Nx 22 https://github.com/awslabs/nx-plugin-for-aws/releases