An SPFx chunk's file name is not its content — realContentHash is off

Symptom

You keep one copy of each lazy chunk across releases — a shared folder on your CDN — and decide what is new by file name, because the name carries a content hash. Then:

• A chunk you know has not changed turns up under a new name in every build, so the shared folder keeps growing. Measured on one app: a 60 kB chunk, byte-identical between two releases, was renamed from chunk.294_7e16…js to chunk.294_54c1…js.
• The dangerous direction is the one you cannot see: nothing guarantees that a toolchain change (a new minifier version, say) will not produce different bytes under a name that already exists. A name-based deduplication then either skips the new file — the new version runs old code — or overwrites the old one, and older versions start loading code they were never built with.

Cause

The webpack configuration that SPFx generates switches the setting off explicitly (@microsoft/spfx-heft-plugins 1.22.2, WebpackConfigurationGenerator.js):

optimization: {
  // TODO: turn this on when webpack5-localization-plugin can suppress RealHashPlugin re-processing files.
  realContentHash: false,
  …
}

while chunk names still use the [contenthash] template. Webpack's own documentation spells out the consequence: with realContentHash set to false, "internal data is used to calculate the hash and it can change when assets are identical". In production mode webpack would default to true; SPFx overrides it.

Fix

• Deduplicate by content, not by name. Compare a hash of the bytes, or — on a git-backed host — the blob that is published (git rev-parse HEAD:<path>) with the blob the new file would become (git hash-object --path <path> <new-file>).
• Never overwrite a published file with different bytes. If a name already exists with other content, publish that release the old, self-contained way (its own folder) instead. A duplicate costs a little space; an overwrite breaks every version that still points at the file.
• Compare blobs, not the SHA of the file on disk. With core.autocrlf=true, a file restored by git checkout sits on disk with CRLF line endings while the commit — and therefore the published site — has LF. A disk hash then reports "different" for identical content; git hash-object --path applies the same conversion a commit would.

Notes

• The shared folder has to live where the library bundle is loaded from: the bundle sets webpack's public path from the address of its own script, so chunks are requested next to it — see A library component loaded from your own manifest fetches its lazy chunks from that manifest's folder.
• Pruning shared chunks needs reference counting from every version that stays, not a date: A retention window computed from git history deletes the file you overwrite in place · CDN pruning deleted the extension bundle the .sppkg still referenced.
• optimization.realContentHash (webpack documentation)
• A vendor chunk can also change for a reason unrelated to the vendor code. Two builds of the same app produced a 393,107-byte chunk of a document-conversion library under two names; the files had the same length and differed in exactly one place — a webpack module id (3665: vs 6046:). One build ran from a git worktree whose node_modules was a junction to the main checkout, and its sources were a few commits apart. Content-based deduplication rightly stored both, so the shared folder grew by the size of a library that had not changed. We did not isolate the cause; production builds derive deterministic module ids from module paths and resolve collisions against the whole module set, and both differed. Build releases from one checkout where you can, and expect vendor chunks to be duplicated when you don't.