ignoreUnusedDeps rewrites the build tsconfig on every build — breaks monorepos where that file is checked in

[Frank-Troia]

We hit this in an Nx monorepo: every build/serve rewrites whatever tsconfig tsConfig points at (reformats include, adds/drops entries), and for us that's the app's real, checked-in tsconfig.app.json. Constant noise in every PR.

Traced it to ignoreUnusedDeps (on by default). When it's on, updateFederationTsConfig() writes the resolved shared-lib entry points into that tsconfig, right before the same file is handed to the Angular compiler for that same build. So it's not just a pruning side effect — those shared libs live outside the app's src/** (reached only via a path mapping), and the Angular compiler won't touch their decorators unless they're listed in include. Turning ignoreUnusedDeps off to stop the churn just breaks the build instead (File '...' not found in TypeScript compilation).

Questions:

• Is mutating the build's own tsconfig meant to double as a permanent, version-controlled file? Would've saved us a while if that were documented somewhere.
• Any chance the entry points could get passed straight to the compiler instead of round-tripping through a file on disk?
• If not, maybe an option to point the rewrite somewhere other than tsConfig (a generated/cache file by default) so monorepo folks don't have to build this themselves.

What we're doing for now: keep ignoreUnusedDeps on, but point tsConfig at a gitignored sibling instead of the real one.

// nx.json
"targetDefaults": {
  "@angular-architects/native-federation:build": {
    "options": { "tsConfig": "{projectRoot}/tsconfig.federation.json" }
  }
}

That file's just:

{ "extends": "./tsconfig.app.json", "include": ["src/**/*.d.ts"] }

seeded by a tiny script we run in prepare so it exists before anyone builds. {projectRoot} gets substituted fine, so it's one config line for every app, no per-project changes needed. Posting the workaround here in case anyone else runs into this before you weigh in.

[Aukevanoost]

Right! Your workaround is pretty much what we are doing in the fix.

The rewrite is gated on optimizedMappings: https://github.com/native-federation/angular-adapter/blob/c2941ef2649629a7255e09b2ef8b595bd598aebb/src/tools/esbuild/angular-bundler.ts#L81-L83, but that flag is just ignoreUnusedDeps coming from core:

native-federation-core/src/lib/core/build/bundle-exposed-and-mappings.ts

Line 86 in 3d38161

optimizedMappings: config.features.ignoreUnusedDeps,

, and that one defaults to true:

native-federation-core/src/lib/config/with-native-federation.ts

Line 40 in 3d38161

ignoreUnusedDeps: config.features?.ignoreUnusedDeps ?? true,

. So it's the default path and you didn't really opt into it. It's also not new, updateFederationTsConfig is in v20.3.8+, v20.4.x, v21.1.8+, v21.2.x and all of v22.x. Before that the adapter wrote a throwaway tsconfig.federation.json next to your config and deleted it again after the build, so it never touched a checked-in file. That answers your first question: no, mutating the build's own tsconfig was never meant to be permanent, we lost that cleanup somewhere along the way.

You can define your own tsconfig file, which is what you already did:

"architect": {
  "build": {
    "builder": "@angular-architects/native-federation:build",
    "options": {
      "tsConfig": "projects/mfe1/tsconfig.federation.json"
    }
  }
}

It takes the tsconfig path from the "esbuild" builder as fallback, which might be your configured tsconfig.app.json: https://github.com/native-federation/angular-adapter/blob/c2941ef2649629a7255e09b2ef8b595bd598aebb/src/builders/build/builder.ts#L214-L217. Two things about your own file: it also drives esbuild's module resolution, so it has to declare or extend the workspace baseUrl/paths (your extends covers that), and it has to stay in the project root, since we take the federation.config.js location and the src/main.ts fallback entry from path.dirname(tsConfig).

Handing the entry points straight to the compiler unfortunately isn't an option, the Angular compiler plugin only accepts a path to a file. But your third suggestion is the right one and it's what native-federation/angular-adapter#124 does: only rewrite a tsconfig when the target declares one itself and otherwise leave the Angular target's tsconfig alone, and own files instead of include so renamed or removed entry points get pruned as well. The schematic seeds that file so the first build is a no-op, and an update22 migration backfills projects that were federated earlier. It also drops the optimizedMappings gate, because with ignoreUnusedDeps: false core hands over every path mapping whether it's used or not and all of them get bundled, which is exactly the File '...' not found in TypeScript compilation you ran into.

So you can keep your setup as is, minus the prepare script once the schematic seeds the file for you.

Hope this helps!