[native-federation] Dev server serves stale shared-mapping bundles until restart (workspace lib edits never trigger federation rebuild)

[arifsisman]

Version: @angular-architects/native-federation 22.0.6, Angular 22.0.7, Nx workspace, esbuild builder (native-federation:build with vite dev server).

Symptom: When a workspace library that is a shared mapping (tsconfig path, e.g. @apex/shell → libs/shell/src/index.ts) is edited while ng serve/nx serve is running, the emitted shared bundle (_apex_shell.js) keeps serving the old code until the dev server is restarted. A hard browser reload does not help.

Root cause (two gaps in src/builders/build/builder.js):

The shared-mapping source directories are never added to the NF file watcher. syncNfFileWatcher relies on bundlerCache.keys(), but in this setup the cache map stays empty (verified by instrumenting syncNfFileWatcher: total 0, watched 0), so the sync is a silent no-op. Since mappings are externals for the app build, Angular's own watcher doesn't cover them either — nothing ever lands in the dirty buffer, so SourceFileCache is never invalidated and ctx.rebuild() reuses the stale TS output.
Even when a watched file changes, the rebuild loop is only woken for npm-linked dirs (if (isUnderLinkedDir(p)) notifyChange()); workspace-mapping edits are expected to "ride the next Angular-driven rebuild", which never comes for external sources.
Fix (patch below): add the mapping entry-point directories to the NF watcher, and wake the rebuild loop for every watched change. With the patch, a lib edit lands in the shared bundle in ~4s (verified by appending/removing a probe export to the mapping entry while the dev server runs).

[Frank-Troia]

Took my agent a while to figure this out, but I'm seeing the same issue.

Independently reproduced the exact same root cause today, but triggered via an exposes entry rather than a sharedMappings lib (editing a component template feeding an exposed route file). Since bundleExposedAndMappingsCore builds shared mappings and exposes together under the same "mapping-or-exposed" adapter context, it's the same code path and same defect — worth noting in case anyone lands here searching only for "exposes" staleness rather than "shared mapping" staleness.

One addition to the root-cause writeup: bundlerCache.keys() isn't just empty in this setup — it's structurally always going to be near-empty, because bundlerCache is Angular's SourceFileCache (@angular/build/src/tools/esbuild/angular/source-file-cache.js), which extends Map but keeps its real per-file cache in two separate properties, not in the outer Map itself:

typeScriptFileCache — a Map of .ts file paths
referencedFiles — an array of resources the compiler tracked as dependencies of a .ts file (.html templates, .scss, etc.) — and this is exactly what SourceFileCache.invalidate() itself checks via extraWatchFiles when deciding what's actually invalid.
So syncNfFileWatcher's [...bundlerCache.keys()] reads the one property that's essentially never populated, and misses both of the properties that matter — which is why both .ts and .html edits are silently dropped, for both exposes and sharedMappings.

Verified locally by patching syncNfFileWatcher in @softarc/native-federation/dist/lib/utils/file-watcher.js:

function syncNfFileWatcher(watcher, bundlerCache) {
const outerKeys = [...bundlerCache.keys()];
const tsKeys = bundlerCache.typeScriptFileCache ? [...bundlerCache.typeScriptFileCache.keys()] : [];
const referenced = bundlerCache.referencedFiles ?? [];
const files = [...new Set([...outerKeys, ...tsKeys, ...referenced])]
.filter((k) => !k.includes("node_modules"));
if (files.length) watcher.addPaths(files);
}
With this in place: on startup the watched-file count went from 0 → 454 for our remote (ts=252 referenced=1274 once node_modules is filtered out), and two consecutive live template edits propagated to the served bundle with zero server restarts — verified by diffing the actual HTTP-served chunk bytes each time.