Coverage emits 0% LCOV for transitive TS deps, causing duplicate/incorrect merged coverage

[CMadden8]

Please provide the environment you discovered this bug in.

NX Angular Windows.

Which area/package is the issue in?

create-analog

Description

#2296

I refer to the above issue raised in relation to this topic.

This problem is not solved.

There is a major issue somewhere that should be possible to reproduce by looking at the raw lcov data that's created.

And even the HTML reports that are generated from these.

There are massive amounts of incorrectly mapped code.

I'm testing on v2.5.2, where the previous fix was applied. I can confirm it does not work.

We built a custom plugin that fixes the mappings. It looks like something like this needs to be part of the AnalogJS library for storybook.

From what I have seen, it adds minimal overhead. So it's not causing any longer build times for CI.

However it is essential.

Please provide the exception or error you saw

Other information

No response

I would be willing to submit a PR to fix this issue

• Yes
• No

[CMadden8]

I asked GPT 5.5 to do a deep-dive analysis of the issue on one file, here referred to as some-test-file.ts. It was able to pinpoint the issue to some transitive deps. It then devised a solution without the mappings plugin. Ran the test again and the problem, at least locally, is gone. I'm testing now in CI.

Here is the report the AI created on the topic:

---

Bug Report

Title

@analogjs/* V8 Storybook coverage emits 0% LCOV for transitive TS deps, causing duplicate/incorrect merged coverage

---

Summary

After upgrading to the latest @analogjs/storybook-angular, @analogjs/vite-plugin-angular, and @analogjs/vitest-angular, we removed our old sourcemap workaround and switched Storybook Vitest to V8 coverage.

We now see a coverage drift for shared dependency files in Jenkins-style Storybook coverage. A file can be 100% covered in unit coverage but appear as 0% covered in Storybook LCOV when it is pulled in transitively through a story import and dependency instrumentation is enabled.

---

Example

• File: some-test-file.ts
• Unit LCOV: 100% lines/functions/branches
• Storybook V8 LCOV: 0/21 lines, 0/8 functions, 0/11 branches
• Sonar/HTML after merging reports: The file shows roughly 52% coverage because both LCOV records are combined.

---

What We Reproduced

• Storybook coverage is run in V8 browser mode.
• A story in some-nx-project imports from some-other-nx-project.
• With COVERAGE_DEPENDENT_PROJECTS enabled, the Storybook LCOV includes:

  some-test-file.ts
  

• That LCOV entry is present but has no hits.
• The exact same file is fully covered in the unit LCOV.

---

Important Detail

This does not look like a JS-path-vs-TS-path issue. The LCOV path is already the correct TypeScript source path. The failure appears to be in how V8/browser coverage is being attributed or included for transitive dependency source files in Storybook coverage.

---

Impact

When Sonar ingests both unit and Storybook LCOVs, shared files get duplicate coverage records. This falsely penalizes the metrics and makes coverage look much lower than it really is.

---

Questions / What We Need to Know

1. Is Storybook V8 coverage expected to include transitive dependency source files at all?
2. If yes, is there a recommended way to prevent zero-hit dependency files from being emitted into LCOV?
3. If not, is this a sourcemap/coverage collection bug in the current V8 browser-mode integration?

---

Environment & Repro Characteristics

• Packages: Latest AnalogJS packages
• Framework: Angular Storybook + Vitest browser coverage
• Coverage Engine: V8 coverage only
• Architecture: Story imports a shared library via package barrel export
• CI Environment: Dependency coverage enabled in Jenkins-style run

[brandonroberts]

Thanks for the detailed follow-up — your updated diagnosis is correct, and it's a different root cause than the original phantom-mapping symptom. I reproduced both.

1. Phantom functions/branches (the original report + #2296): Angular's AOT emit (ɵfac/ɵcmp + the ɵsetClassMetadata/ɵsetClassDebugInfo calls) was being mapped back onto your decorators/class/constructor, so coverage invented functions and branches there. @analogjs/vite-plugin-angular now strips those generated members from the test sourcemap (#2350). This is the part a "mappings plugin" addressed.

2. Transitive deps reporting 0% (your updated comment): confirmed, and as you said it's not a JS-vs-TS path issue. When a story imports a shared library through its package/barrel entry, Vite pre-bundles it and serves it from node_modules/.vite/deps. @vitest/coverage-v8's browser collector ignores any module served from node_modules, so the dep records 0 hits at its correct source path even though it ran — and merging that with the unit LCOV double-counts the file. I reproduced this with a minimal, Angular-free project.

Fix: keep those workspace deps out of Vite's pre-bundling so they're served (and instrumented) from source:

export default defineConfig({
  optimizeDeps: { exclude: ['@my-org/ui'] },
  test: { server: { deps: { inline: ['@my-org/ui'] } } },
});

(Or scope coverage.include to the current project so dependent-project sources aren't emitted as zero-hit records.)

Both the synthetic-mapping fix and this coverage guidance (including the transitive-dep pitfall, under "Monorepo configuration" in the Storybook guide) are in #2350.

[brandonroberts]

Quick correction to my earlier comment: the synthetic-mapping ("phantom functions/branches") fix I referenced has been dropped from #2350.

On closer inspection that symptom only appears under AOT test compilation (jit: false), whereas both Vitest unit tests and @analogjs/storybook-angular default to JIT — and in JIT the phantom mappings don't occur (Angular doesn't emit the ɵcmp template function or its change-detection branches). So no code change is needed for the default setup.

The real, reproducible issue is the monorepo one above: a transitive workspace dependency imported via its package/barrel is pre-bundled and served from node_modules, where browser V8 coverage ignores it, so it shows 0 hits at its source path and double-counts when merged with the unit report. #2350 now documents that in the Storybook guide with the optimizeDeps.exclude / viteFinal workaround — which I verified end-to-end against the @analogjs/storybook-angular + @storybook/addon-vitest browser-coverage pipeline.

[CMadden8]

@brandonroberts I've tried everything suggested - it doesn't fix the problem. I've had to reinstate the custom sourcemap mapping solution...

There isn't an expectation that analogjs creates an alternative fix. I'm just noting it for any others who encounter the problem.

Storybook seem to have offically abandoned Angular in terms of Vite/Vitest support, and perhaps that's a clue as to why this is such a stubborn issue

[brandonroberts]

Thanks @CMadden8. I looked at the source map plugin but it only applied to AOT which doesn't help Storybook.

I'm working with the Storybook team on an official Storybook Angular Vite package so anything we find here will go upstream

[CMadden8]

Thanks @brandonroberts - that's promising news, I'd thought Angular abandoned by the SB team... It'd be great to have official Storybook support for Angular and Vite/Vitest - obviously this is a complex topic...

We have a solution on our end, but it does seem a 'hack'. And it's still unclear why it's needed. It's a 10% global drop in coverage for about 30 Angular NX projects without it...

Again, there's no expectation that AnalogJS addresses this.

Appreciate the feedback and best of luck creating an official Angular Storybook Vite/Vitest.