Expose internal "instrumentForCoverage" option

Inizia con @angular/build/src/builders/application/schema.json e @angular/build/src/tools/esbuild/angular/compiler-plugin.js, quindi traccia il percorso con cui le opzioni dell’application builder raggiungono il compiler plugin. Controlla i test esistenti del builder e del compiler-plugin prima di rendere disponibile l’opzione e considera il lavoro completato quando l’opzione viene accettata, strumenta il codice dell’applicazione previsto ed esclude node_modules dalla raccolta della coverage.

Command

build

Description

E2E test runners like Cypress, in order to collect code coverage data, require the code served by the dev-server to be instrumented. I'd like the built-in builder to let me do exactly that, considering the fact that it can.

Describe the solution you'd like

I'd like to be able to specify "instrumentForCoverage": true in my @angular/build:application options and be done with it. I've patched my node modules to see what that would look like and it works like a charm: @cypress/code-coverage is generating the reports, the node_modules are excluded, and I'm able to use the same builder for E2E and prod builds.

In the next section I've collected some of the hoops I had to jump through to get close (but fail to attain) this level of integration. By the end of the read, I hope you'll agree with me that a built-in solution (considering it's already coded!) would be a step-up in terms of developer experience.

In the meantime, for reference, here's the quick-n-dirty patch.

diff --git a/node_modules/@angular/build/src/builders/application/schema.json b/node_modules/@angular/build/src/builders/application/schema.json
index 3ee8699..0b893a0 100755
--- a/node_modules/@angular/build/src/builders/application/schema.json
+++ b/node_modules/@angular/build/src/builders/application/schema.json
@@ -47,6 +47,10 @@
       "type": "string",
       "description": "Customize the base path for the URLs of resources in 'index.html' and component stylesheets. This option is only necessary for specific deployment scenarios, such as with Angular Elements or when utilizing different CDN locations."
     },
+    "instrumentForCoverage": {
+      "type": "boolean",
+      "description": "Enables instrumentation to collect code coverage data for specific files."
+    },
     "security": {
       "description": "Security features to protect against XSS and other common attacks",
       "type": "object",
diff --git a/node_modules/@angular/build/src/tools/esbuild/angular/compiler-plugin.js b/node_modules/@angular/build/src/tools/esbuild/angular/compiler-plugin.js
index 675ae15..ab42aab 100755
--- a/node_modules/@angular/build/src/tools/esbuild/angular/compiler-plugin.js
+++ b/node_modules/@angular/build/src/tools/esbuild/angular/compiler-plugin.js
@@ -354,7 +354,7 @@ function createCompilerPlugin(pluginOptions, compilationOrFactory, stylesheetBun
                     // A string indicates untransformed output from the TS/NG compiler.
                     // This step is unneeded when using esbuild transpilation.
                     const sideEffects = await hasSideEffects(request);
-                    const instrumentForCoverage = pluginOptions.instrumentForCoverage?.(request);
+                    const instrumentForCoverage = pluginOptions.instrumentForCoverage; //?.(request);
                     contents = await javascriptTransformer.transformData(request, contents, true /* skipLinker */, sideEffects, instrumentForCoverage);
                     // Store as the returned Uint8Array to allow caching the fully transformed code
                     typeScriptFileCache.set(request, contents);

Describe alternatives you've considered

In my search, for Angular 20, I've found only one semi-working[1] solution that requires a 3rd-party builder (@angular-builder/custom-webpack) based on Webpack. That might sound like I haven't done any due diligence, when in fact I have.

• @angular-builder/custom-esbuild with esbuild-plugin-istanbul doesn't work because the onLoad callback of an esbuild plugin (such as the one defined by the istanbul plugin) is called only as long as no previous plugin handled the resource that's being loaded, and the angular-compiler handles them all.

  • A possible solution could be a custom plugin that overrides the default namespace of each resource we may want to instrument (with onResolve), which would effectively sidestep the Angular compiler BUT force the plugin author to reimplement the compilation. Very high effort.

• A Vite plugin (rather than an esbuild one) could work, but the Angular builder is not based on Vite. @analogjs/vite-plugin-angular is, but it doesn't have a builder, only an executor for @nx, which is another can of worms. In short, the migration path isn't straightforward at all, and let's remember: this is all to add instrumentation!

• I've considered trying Angular Rspack, but it's still experimental. I want my E2E tests to be as close to my production environment as they can get, and using two different builders (one for prod and one for e2e) is not an option.

• Finally, of course, the @angular/build package doesn't do instrumentation. Not through the builder schema anyway.

Apart from my lack of Webpack knowledge (see footnote), it appears to me that the setup I found is still not ideal. Some reasons:

1. Angular moved away from Webpack. The happy path--aka, the officially supported path--is esbuild, not Webpack.
2. Webpack is slower than esbuild in most cases. Not a big deal but I'm sure there are some peeps who'd be very impacted by that.
3. No third-party esbuild-based builder that makes use of the official devkit/extends the @angular/build builder will ever be able to offer a different experience. Any plugin passed to the builder will always be appended to the end of the list of plugins, after the angular compiler. Ergo, no onLoad callbacks.

[1] I say semi-working 'cause I don't know Webpack enough--but who does 😆--and didn't manage to add the instrumentation to the un-chunked code, which regrettably leads to instrumented node_modules