diff --git a/packages/compiler-cli/ngcc/test/BUILD.bazel b/packages/compiler-cli/ngcc/test/BUILD.bazel
index 80ff42aa20..401ba9a381 100644
--- a/packages/compiler-cli/ngcc/test/BUILD.bazel
+++ b/packages/compiler-cli/ngcc/test/BUILD.bazel
@@ -64,13 +64,14 @@ ts_library(
     ],
 )
 
-# As of version 10, the release packages do not contain esm2015 output anymore. The ngcc
-# integration tests intend to test ES5 features though, so we downlevel the flat esm2015
-# file to ES5 using Babel. We can then link that into the mock file system as if the Angular
-# core package is still built with previous APF versions where esm5 output was shipped. This
-# allows us to ensure that ngcc properly processes libraries with esm5 output. **Note**: We are
-# using Babel instead of `tsc` as TypeScript does not allow us to downlevel the file without
-# setting the module resolution to either `amd` or `system`. We want to preserve ES modules.
+# As of version 10, the release packages do not contain esm5 output anymore. The ngcc integration
+# tests intend to test ES5 features though, so we downlevel the flat esm2015 file to ES5 using
+# Babel. We can then link that into the mock file system as if the Angular core package is still
+# built with previous APF versions where esm5 output was shipped. This allows us to ensure that ngcc
+# properly processes libraries with esm5 output.
+# **Note**: We are using Babel instead of `tsc` as TypeScript does not allow us to downlevel the
+# file without setting the module resolution to either `amd` or `system`. We want to preserve ES
+# modules.
 babel(
     name = "fesm5_angular_core",
     outs = ["fesm5_angular_core.js"],
diff --git a/packages/compiler-cli/ngcc/test/integration/util.ts b/packages/compiler-cli/ngcc/test/integration/util.ts
index 045582ae8b..53f272cb23 100644
--- a/packages/compiler-cli/ngcc/test/integration/util.ts
+++ b/packages/compiler-cli/ngcc/test/integration/util.ts
@@ -20,8 +20,8 @@ export type PackageSources = {
 /**
  * Instead of writing packaged code by hand, and manually describing the layout of the package, this
  * function transpiles the TypeScript sources into a flat file structure using the ES5 format. In
- * this package layout, all compiled sources are at the root of the package, with .d.ts files next
- * to the .js files. Each .js also has a corresponding .metadata.js file alongside with it.
+ * this package layout, all compiled sources are at the root of the package, with `.d.ts` files next
+ * to the `.js` files. Each `.js` also has a corresponding `.metadata.json` file alongside with it.
  *
  * All generated code is written into the `node_modules` in the top-level filesystem, ready for use
  * in testing ngcc.
@@ -41,7 +41,7 @@ export function compileIntoFlatEs5Package(pkgName: string, sources: PackageSourc
  * Instead of writing packaged code by hand, and manually describing the layout of the package,
  * this function transpiles the TypeScript sources into a flat file structure using the ES2015
  * format. In this package layout, all compiled sources are at the root of the package, with
- * `.d.ts` files next to the `.js` files. Each `.js` also has a corresponding `.metadata.js`
+ * `.d.ts` files next to the `.js` files. Each `.js` also has a corresponding `.metadata.json`
  * file alongside with it.
  *
  * All generated code is written into the `node_modules` in the top-level filesystem, ready for use
@@ -78,8 +78,8 @@ export interface FlatLayoutOptions {
 /**
  * Instead of writing packaged code by hand, and manually describing the layout of the package, this
  * function transpiles the TypeScript sources into a flat file structure using a single format. In
- * this package layout, all compiled sources are at the root of the package, with .d.ts files next
- * to the .js files. Each .js also has a corresponding .metadata.js file alongside with it.
+ * this package layout, all compiled sources are at the root of the package, with `.d.ts` files next
+ * to the `.js` files. Each `.js` also has a corresponding `.metadata.json` file alongside with it.
  *
  * All generated code is written into the `node_modules` in the top-level filesystem, ready for use
  * in testing ngcc.