#36136)

## Current Behavior

`NxAppRspackPlugin` maps `outputHashing: 'all'` (the default) to two
different hash placeholders: `output.filename` uses `[contenthash]`, but
`output.chunkFilename` uses `[chunkhash]`. rspack's `[chunkhash]` hashes
a chunk's module bodies but not each contained module's assigned id.
With the production default `optimization.moduleIds: 'deterministic'`, a
module's id can be renumbered by an unrelated change to the module
graph, which changes a chunk's emitted bytes without changing its
`[chunkhash]` filename. Long-term-cached clients then keep the old chunk
against a freshly built entry that references the new id and crash with
`Uncaught TypeError: Cannot read properties of null (reading 'call')`.
`optimization.realContentHash` does not mitigate this, since it only
re-hashes `[contenthash]`.

## Expected Behavior

`output.chunkFilename` uses `[contenthash]`, matching `output.filename`,
so a chunk's filename always changes when its emitted content does. This
is rspack's recommended hash for long-term caching and matches the
defaults of Angular CLI, create-react-app, and Vue CLI.

## Implementation Details

`getOutputHashFormat` in
`packages/rspack/src/plugins/utils/hash-format.ts` now uses
`[contenthash]` for `chunk` in both the `bundles` and `all` options.
Confirmed against rspack source: `[contenthash]` folds the module id
into the hash (web-infra-dev/rspack#2292, released in v0.1.2, below the
`@rspack/core ^1 || ^2` support floor) while `[chunkhash]` does not.

`@nx/webpack` carries the same `[chunkhash]` default but was
deliberately left unchanged: webpack's `[chunkhash]` already folds
module ids into the chunk hash (via `getModuleHash`), so it does not
exhibit this stale-chunk problem.

## Related Issue(s)

Fixes #36014

<!-- polygraph-session-start -->
---
[View session information
↗](https://app.trypolygraph.com/orgs/6a061dcb561c062131116eca/sessions/gh-36014-54fdd58d)
<!-- polygraph-session-end -->

#36136)

## Current Behavior

`NxAppRspackPlugin` maps `outputHashing: 'all'` (the default) to two
different hash placeholders: `output.filename` uses `[contenthash]`, but
`output.chunkFilename` uses `[chunkhash]`. rspack's `[chunkhash]` hashes
a chunk's module bodies but not each contained module's assigned id.
With the production default `optimization.moduleIds: 'deterministic'`, a
module's id can be renumbered by an unrelated change to the module
graph, which changes a chunk's emitted bytes without changing its
`[chunkhash]` filename. Long-term-cached clients then keep the old chunk
against a freshly built entry that references the new id and crash with
`Uncaught TypeError: Cannot read properties of null (reading 'call')`.
`optimization.realContentHash` does not mitigate this, since it only
re-hashes `[contenthash]`.

## Expected Behavior

`output.chunkFilename` uses `[contenthash]`, matching `output.filename`,
so a chunk's filename always changes when its emitted content does. This
is rspack's recommended hash for long-term caching and matches the
defaults of Angular CLI, create-react-app, and Vue CLI.

## Implementation Details

`getOutputHashFormat` in
`packages/rspack/src/plugins/utils/hash-format.ts` now uses
`[contenthash]` for `chunk` in both the `bundles` and `all` options.
Confirmed against rspack source: `[contenthash]` folds the module id
into the hash (web-infra-dev/rspack#2292, released in v0.1.2, below the
`@rspack/core ^1 || ^2` support floor) while `[chunkhash]` does not.

`@nx/webpack` carries the same `[chunkhash]` default but was
deliberately left unchanged: webpack's `[chunkhash]` already folds
module ids into the chunk hash (via `getModuleHash`), so it does not
exhibit this stale-chunk problem.

## Related Issue(s)

Fixes #36014

<!-- polygraph-session-start -->
---
[View session information
↗](https://app.trypolygraph.com/orgs/6a061dcb561c062131116eca/sessions/gh-36014-54fdd58d)
<!-- polygraph-session-end -->

(cherry picked from commit 15871f0)

…eywords (#36326)

## Current Behavior

`nx release changelog` extracts issue references from the commit body
with a bare `/(#\d+)/gm` regex, so **every** `#number` in a squashed PR
description becomes an issue link in the changelog — including other
repos' issue numbers.

For example, the [23.1.0 release
notes](https://github.com/nrwl/nx/releases/tag/23.1.0) contain:

> **rspack:** support @rspack/core@2 and @rsbuild/core@2 (multi-version
compliance) (#35682, #35764, #13420, #781)

where `#13420` is actually `web-infra-dev/rspack#13420` and `#781` is
`privatenumber/tsx#781` — upstream issues discussed in the PR
description, rendered as (bogus) `nrwl/nx` issue links. The same release
also picked up `nrwl/nx-console#3175`, `react/react#418`, and
`web-infra-dev/rspack#2292`, plus noisy same-repo PR mentions that were
merely referenced in prose.

## Expected Behavior

Issue references are only extracted from the commit body when linked via
a GitHub closing keyword (`Fixes #123`, `Closes #123`, `Resolves: #123`,
...) — the same rule GitHub itself uses to auto-link and close issues.
Cross-repo forms (`owner/repo#123`), markdown links to other repos, and
casual same-repo mentions no longer produce changelog references.

Subject-line extraction (the PR number in `(#123)` and inline issue
refs) is unchanged. Both regular commits and version plans go through
the same `extractReferencesFromCommit` function, so this fixes both
paths.

## Related Issue(s)

N/A

<!-- polygraph-session-start -->
---
[View session information
↗](https://app.trypolygraph.com/orgs/6a061dcb561c062131116eca/sessions/Fix-nx-release-changelog-scraping-other-repos-issue-numbers-7967dd62)
<!-- polygraph-session-end -->

…eywords (#36326)

## Current Behavior

`nx release changelog` extracts issue references from the commit body
with a bare `/(#\d+)/gm` regex, so **every** `#number` in a squashed PR
description becomes an issue link in the changelog — including other
repos' issue numbers.

For example, the [23.1.0 release
notes](https://github.com/nrwl/nx/releases/tag/23.1.0) contain:

> **rspack:** support @rspack/core@2 and @rsbuild/core@2 (multi-version
compliance) (#35682, #35764, #13420, #781)

where `#13420` is actually `web-infra-dev/rspack#13420` and `#781` is
`privatenumber/tsx#781` — upstream issues discussed in the PR
description, rendered as (bogus) `nrwl/nx` issue links. The same release
also picked up `nrwl/nx-console#3175`, `react/react#418`, and
`web-infra-dev/rspack#2292`, plus noisy same-repo PR mentions that were
merely referenced in prose.

## Expected Behavior

Issue references are only extracted from the commit body when linked via
a GitHub closing keyword (`Fixes #123`, `Closes #123`, `Resolves: #123`,
...) — the same rule GitHub itself uses to auto-link and close issues.
Cross-repo forms (`owner/repo#123`), markdown links to other repos, and
casual same-repo mentions no longer produce changelog references.

Subject-line extraction (the PR number in `(#123)` and inline issue
refs) is unchanged. Both regular commits and version plans go through
the same `extractReferencesFromCommit` function, so this fixes both
paths.

## Related Issue(s)

N/A

<!-- polygraph-session-start -->
---
[View session information
↗](https://app.trypolygraph.com/orgs/6a061dcb561c062131116eca/sessions/Fix-nx-release-changelog-scraping-other-repos-issue-numbers-7967dd62)
<!-- polygraph-session-end -->

…eywords (#36326)

## Current Behavior

`nx release changelog` extracts issue references from the commit body
with a bare `/(#\d+)/gm` regex, so **every** `#number` in a squashed PR
description becomes an issue link in the changelog — including other
repos' issue numbers.

For example, the [23.1.0 release
notes](https://github.com/nrwl/nx/releases/tag/23.1.0) contain:

> **rspack:** support @rspack/core@2 and @rsbuild/core@2 (multi-version
compliance) (#35682, #35764, #13420, #781)

where `#13420` is actually `web-infra-dev/rspack#13420` and `#781` is
`privatenumber/tsx#781` — upstream issues discussed in the PR
description, rendered as (bogus) `nrwl/nx` issue links. The same release
also picked up `nrwl/nx-console#3175`, `react/react#418`, and
`web-infra-dev/rspack#2292`, plus noisy same-repo PR mentions that were
merely referenced in prose.

## Expected Behavior

Issue references are only extracted from the commit body when linked via
a GitHub closing keyword (`Fixes #123`, `Closes #123`, `Resolves: #123`,
...) — the same rule GitHub itself uses to auto-link and close issues.
Cross-repo forms (`owner/repo#123`), markdown links to other repos, and
casual same-repo mentions no longer produce changelog references.

Subject-line extraction (the PR number in `(#123)` and inline issue
refs) is unchanged. Both regular commits and version plans go through
the same `extractReferencesFromCommit` function, so this fixes both
paths.

## Related Issue(s)

N/A

<!-- polygraph-session-start -->
---
[View session information
↗](https://app.trypolygraph.com/orgs/6a061dcb561c062131116eca/sessions/Fix-nx-release-changelog-scraping-other-repos-issue-numbers-7967dd62)
<!-- polygraph-session-end -->

(cherry picked from commit d7312d2)