build: fix release output containing invalid imports sometimes (#20214)

A very subtle issue has surfaced in our release output. Based on
previous builds that have been performed locally by the caretaker
performing the release, the release output might differ and contain
invalid module imports that break ES2015 output.

Notably the es2015 output is not primarily used by the CLI. It uses
the flat ES2015 output instead.

The issue surfaces because of a bug in `@bazel/typescript` where the
`moduleName` for source files is leaking between TSC worker runs. This
means that source files are incorrectly referenced by module name,
instead of relative path when the prodmode ES2015 output is built.
Deep paths to source files are not supported as per Angular Package format.

We patch the fix that is pending upstream to ensure our release output
works: bazelbuild/rules_typescript#504. Once the
fix upstream lands (which might take quite some time; given g3 sync and
sync with the rules_nodejs repository), we can remove the patch and
update to the latest version of `@bazel/typescript`.

Fixes #20179.

Author: devversion

tools/postinstall/@bazel_typescript_tsc_wrapped_worker_cache_fix.patch

@@ -0,0 +1,34 @@
+diff --git node_modules/@bazel/typescript/internal/tsc_wrapped/compiler_host.js node_modules/@bazel/typescript/internal/tsc_wrapped/compiler_host.js
+index 031d9dad1..a7fe9b79b 100644
+--- node_modules/@bazel/typescript/internal/tsc_wrapped/compiler_host.js
++++ node_modules/@bazel/typescript/internal/tsc_wrapped/compiler_host.js
+@@ -377,10 +377,27 @@ class CompilerHost {
+                         `which would be overwritten with ${moduleName} ` +
+                         `by Bazel's TypeScript compiler.`);
+                 }
+-                // Setting the moduleName is equivalent to the original source having a
+-                // ///<amd-module name="some/name"/> directive
++
++                // Setting the moduleName is equivalent to the original source having the triple
++                // slash `///<amd-module name="some/name"/>` directive. Also note that we tag
++                // source files for which we assigned a generated module name. This is necessary
++                // so that we can reset the module name when the same source file is loaded from
++                // a cache, but with a different module format where the auto-generated module
++                // names are not desirable. The module name should not leak from previous
++                // compilations through a potential source file cache.
++                sf._hasGeneratedAmdModuleName = true;
+                 sf.moduleName = moduleName;
++                return sf;
+             }
++
++            // If the loaded source file has a generated amd module name applied from
++            // previous compilations (in worker mode), reset the file module name
++            // as neither the UMD or AMD module format is used (for which we generate
++            // the AMD module names automatically).
++            if (sf._hasGeneratedAmdModuleName) {
++                sf.moduleName = undefined;
++            }
++
+             return sf;
+         });
+     }

tools/postinstall/apply-patches.js

@@ -14,7 +14,7 @@ const chalk = require('chalk');
  * Version of the post install patch. Needs to be incremented when
  * existing patches or edits have been modified.
  */
-const PATCH_VERSION = 6;
+const PATCH_VERSION = 9;
 
 /** Path to the project directory. */
 const projectDir = path.join(__dirname, '../..');
@@ -110,6 +110,9 @@ function applyPatches() {
   // Workaround for: https://github.com/bazelbuild/rules_nodejs/issues/1208.
   applyPatch(path.join(__dirname, './manifest_externs_hermeticity.patch'));
 
+  // Patches the changes from: https://github.com/bazelbuild/rules_typescript/pull/504.
+  applyPatch(path.join(__dirname, './@bazel_typescript_tsc_wrapped_worker_cache_fix.patch'));
+
   // Workaround for https://github.com/angular/angular/issues/33452:
   searchAndReplace(
       /angular_compiler_options = {/, `$&