Builder updates the federation tsconfig but never creates it, so a fresh clone fails with ENOENT

[Ionaru]

Summary

The builder rewrites the federation tsconfig on every build, adding the resolved entry points to its include, but it never creates that file. If the configured tsconfig does not exist, the build fails with ENOENT instead of generating it.

This matters because the file is generated output that some setups gitignore, so a fresh clone cannot build until someone recreates it by hand.

Affected versions

• @angular-architects/native-federation-v4@20.4.3 (dist-tag v20-support)
• @angular-architects/native-federation-v4@21.2.8 (dist-tag latest)

Cause

src/utils/create-federation-tsconfig.js:

export function updateFederationTsConfig(workspaceRoot, tsConfigPath, entryPoints) {
  // ...
  const tsconfigAsString = fs.readFileSync(fullTsConfigPath, 'utf-8');
  // ...
  fs.writeFileSync(fullTsConfigPath, JSON.stringify(tsconfig, null, 2));

The read is unconditional, so a missing file throws rather than being created. The function is named update…, and nothing else creates it.

Reproduction

1. Point the builder at a dedicated tsconfig via its tsConfig option, e.g. "tsConfig": "apps/<app>/tsconfig.federation.json".
2. Delete that file (or clone a repository that gitignores it).
3. ng build

ERRR  Error building federation artifacts
ERRR  ENOENT: no such file or directory, open '<path>/tsconfig.federation.json'

Expected: the builder creates the file, as it does for its other generated artifacts.

Related consequence

With no tsConfig option set, the builder defaults to the application's own tsconfig and rewrites that on every build. The result is a tracked source file that is modified after every build, leaving a permanently dirty working tree, and whose formatting is owned by the builder rather than the repository's formatter. Pointing the option at a dedicated file avoids that, but then hits the ENOENT above.

Related

#29 asked for the tsconfig to be created by the schematic rather than the builder, and was closed. The behaviour described here is still present in the v4 bridge releases above, so either the schematic creating it or the builder creating it when missing would resolve this.