fix(@angular/build): apply file replacements to web worker entry bundles

[maruthang]

Summary

• Current behavior: fileReplacements entries in angular.json are silently ignored when building web workers with the esbuild application builder. Workers always bundle the original (un-replaced) files even when a production build configuration specifies replacements.
• New behavior: File replacements are correctly applied to web worker entry bundles. Import specifiers in the worker entry file are rewritten to point to the replacement files before the synchronous esbuild sub-build runs.
• Root cause: bundleWebWorker uses build.esbuild.buildSync() with plugins: undefined. The main build applies file replacements via Angular compiler plugin onLoad hooks, which are unavailable in synchronous esbuild builds.

The fix rewrites the worker entry file's import specifiers before bundling: each relative/absolute specifier is resolved to an absolute path, checked against the fileReplacements map, and replaced with the absolute path of the replacement file when a match is found. The modified content is passed via stdin so esbuild resolves and bundles the replacement files normally.

Closes #29546

Test plan

• New regression test should apply file replacements inside web workers in file-replacements_spec.ts verifies the worker bundle contains the replaced value and not the original
• Existing should replace JSON files test continues to pass
• Build a project with a web worker that imports an environment file covered by fileReplacements and verify the production bundle uses the replacement

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request implements file replacement support for web workers by manually rewriting import and export specifiers in the worker entry file, addressing a limitation in esbuild's synchronous API. It also enhances the CLI update command to correctly supplement dependency maps with local packages in workspace configurations. Review feedback suggests improving the robustness of the rewriting logic by using anchored regex patterns, handling special characters in replacement paths, and supporting directory-based imports.

[gemini-code-assist]

The manual rewriting of import specifiers in the worker entry file has several limitations and potential issues:

1. Transitive Imports: This approach only applies replacements to the entry file. Any imports within the dependency graph of the worker (i.e., files imported by the entry file) will not have replacements applied because esbuild.buildSync does not support plugins. This is a significant limitation if shared services or constants (which might import the environment) are used in the worker.
2. Regex Robustness: The current regex can match import/export keywords inside comments or strings. Since these must be top-level statements in ESM, it's safer to anchor the regex to the start of the line.
3. Replacement Safety: Using String.prototype.replace with a string as the second argument (line 843) can lead to incorrect output if the replacement path contains special characters like $ (e.g., in some Windows paths).
4. Resolution Logic: The manual resolution (lines 818-831) doesn't handle directory imports (e.g., import './utils' resolving to ./utils/index.ts).

While the transitive imports issue is an architectural limitation of the synchronous worker bundling, the other issues can be mitigated by using a more robust replacement approach.

[gemini-code-assist]

Consider using a more robust replacement logic that anchors to the start of the line and uses a callback function to avoid issues with special characters in paths. This also simplifies the loop and avoids manual string manipulation.

  // Matches static import/export specifiers at the start of a line:
  // Captures the prefix (group 1), quote (group 2), specifier (group 3), and closing quote (group 2).
  const importExportRe = /^(\s*(?:import|export)\b[^;'"\n]*?(['"]))([^'"\n]+)(\2)/gm;

  // Extensions to try when resolving a specifier without an explicit extension.
  const candidateExtensions = ['.ts', '.tsx', '.mts', '.cts', '.js', '.mjs', '.cjs'];

  return contents.replace(importExportRe, (fullMatch, prefix, quote, specifier) => {
    // Only process relative specifiers; bare package-name imports are not file-path replacements.
    if (!specifier.startsWith('.') && !path.isAbsolute(specifier)) {
      return fullMatch;
    }

    const resolvedBase = path.isAbsolute(specifier)
      ? specifier
      : path.join(workerDir, specifier);

    let replacementPath: string | undefined;

    // First check if the specifier already includes an extension and resolves directly.
    const directCandidate = path.normalize(resolvedBase);
    replacementPath = fileReplacements[directCandidate];

    if (!replacementPath) {
      // Try appending each supported extension to resolve extensionless specifiers.
      for (const ext of candidateExtensions) {
        const candidate = path.normalize(resolvedBase + ext);
        replacementPath = fileReplacements[candidate];
        if (replacementPath) {
          break;
        }
      }
    }

    if (replacementPath) {
      const newSpecifier = replacementPath.replaceAll('\\', '/');
      return prefix + newSpecifier + quote;
    }

    return fullMatch;
  });