fix(jest)!: scope coverage output per-project in multi-project workspaces (fixes #1009)#2212
Merged
Merged
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
just-jeb
force-pushed
the
fix/1009-coverage-namespacing
branch
7 times, most recently
from
1194137 to
21eccdd
Compare
Owner
Author
|
Potentially breaking? |
just-jeb
force-pushed
the
fix/1009-coverage-namespacing
branch
2 times, most recently
from
426d01c to
4f6f462
Compare
Owner
Author
|
Re: 'Potentially breaking?' Yes — it changes coverage output from Treating this as a breaking change: labeling |
2 tasks
just-jeb
added a commit
that referenced
this pull request
Jun 2, 2026
- spec §12: Karma deprecated-not-removed in v22; drop custom-webpack @22 migration + hold #2260; add jest Vitest→Jest path; add custom-esbuild webpack-build guard; fix e2e fixtures - spec §4.3/§5: custom-webpack ng-add-only; v22 breaking set = #2191+#2212 - 2c/2d checklist: #2260 off the v22 holds, Karma fixture via ng new, e2e cases
2 tasks
just-jeb
added a commit
that referenced
this pull request
Jun 3, 2026
just-jeb
added a commit
that referenced
this pull request
Jun 3, 2026
- spec §12: Karma deprecated-not-removed in v22; drop custom-webpack @22 migration + hold #2260; add jest Vitest→Jest path; add custom-esbuild webpack-build guard; fix e2e fixtures - spec §4.3/§5: custom-webpack ng-add-only; v22 breaking set = #2191+#2212 - 2c/2d checklist: #2260 off the v22 holds, Karma fixture via ng new, e2e cases
just-jeb
force-pushed
the
fix/1009-coverage-namespacing
branch
from
f5a57cb to
8f1c43d
Compare
2 tasks
just-jeb
changed the title
just-jeb
added a commit
that referenced
this pull request
Jun 4, 2026
…webpack (#2267) * docs(schematics): add v22 builder ng-add + ng-update design spec * docs(schematics): cover v22-held breaking PRs (#2191/#2212) and MIGRATION.MD pairing * docs(schematics): add Plan 0 — common/schematics core + packaging * docs(schematics): add Plans 01-03 — jest, custom-esbuild, custom-webpack Builder implementation plans referencing Plan 0's locked common/schematics API contract. Reviewed for consistency: all import the shared helpers, none redefine them, no raw fs (tree-based edits only). * docs(schematics): add v17→v22 migration coverage caveat + 2c/2d execution checklist - jest plan: document the stepwise-through-v21 skip + single-step old→22 flow and RC-time multi-major ng update validation - new 2c/2d checklist: holds rebase, MIGRATION.MD pairing, RC validations, and the two e2e testing gaps (ng add integration, jest @21 post-migration smoke) * docs(schematics): amend design for Karma roadmap (not removed in v22) - spec §12: Karma deprecated-not-removed in v22; drop custom-webpack @22 migration + hold #2260; add jest Vitest→Jest path; add custom-esbuild webpack-build guard; fix e2e fixtures - spec §4.3/§5: custom-webpack ng-add-only; v22 breaking set = #2191+#2212 - 2c/2d checklist: #2260 off the v22 holds, Karma fixture via ng new, e2e cases * docs(schematics): apply §12 amendments to builder plans - jest (Plan 01): add Vitest→Jest ng-add path (Task 4b), keep Karma→Jest - custom-esbuild (Plan 02): add webpack-build guard + --from-webpack (Task 3b) - custom-webpack (Plan 03): drop @22 Karma-removal migration, ng-add only Reviewed: no shared-helper redefinition, no raw fs in schematic code, webpack @22 migration fully removed (remaining refs assert its absence). * docs(schematics): add Plan 04 — schematics integration/e2e tests ng add e2e per builder (jest Karma→Jest + Vitest→Jest, esbuild build + webpack guard, webpack scaffold) via npm pack→ng add tarball into the existing integration matrix; jest @21 post-migration build smoke; RC multi-major ng update validation. * build(common): add schematics subpath packaging (tsconfig + exports + copy) * feat(common): add schematics version helpers * feat(common): add SchematicTestHarness for schematics unit tests Also stubs ESM-only `ora` (via @angular-devkit/schematics task executor chain) with a moduleNameMapper in jest-ut.config.js, and resolves @schematics/angular/collection.json via package.json to bypass the exports map (required in Node 22+). * feat(common): add workspace detection helpers for schematics * feat(common): add composable schematics rule factories * feat(common): export schematics core via ./schematics subpath * build(jest): add schematics packaging (tsconfig + fields + copy) * feat(jest): add ng-add collection + schema (project flag only) * feat(jest): ng-add adds jest stack and rewrites test target * feat(jest): declare ng-update migrations manifest (v21, v22) * feat(jest): v21 migration bumps deps and applies Node16 tsconfig * feat(jest): v22 advisory migration (isolatedModules, coverage path) * build(custom-esbuild): add schematics packaging (tsconfig + ng-add fields + copy) * feat(custom-esbuild): add ng-add collection + schema manifests * feat(custom-esbuild): ng-add rewrites build/serve preserving options * feat(custom-esbuild): ng-add guards webpack builds, adds --from-webpack (spec §12.3) * feat(custom-esbuild): ng-add auto-rewrites Vitest test target with buildTarget * feat(custom-esbuild): ng-add leaves Karma/Jest tests, logs unit-test advisory * feat(custom-esbuild): ng-add --unit-test force-creates Vitest target * test(custom-esbuild): assert ng-add idempotency * build(custom-esbuild): verify schematics build * build(custom-webpack): add schematics packaging (tsconfig + ng-add field) * feat(custom-webpack): add ng-add schema (project flag, no prompts) * feat(custom-webpack): add starter webpack.config scaffold template * feat(custom-webpack): add ng-add (build/serve rewrite + config scaffold) * test(custom-webpack): verify schematics build + no-migrations invariant * fix(jest): add WorkspaceDefinition casts and JsonValue fixes for schematics tsc * test(schematics): add local-only ng add e2e harness helpers * build(schematics): use Node16 module resolution for schematics build The schematics tsconfig used module:commonjs + moduleResolution:node (node10). node10 is deprecated in TypeScript 6 (Angular 22) AND ignores package exports maps — the latter is why each package's schematics tsconfig carried a 'paths' override just to resolve @angular-builders/common/schematics. Align with the main builder tsconfig (module/moduleResolution Node16): all packages are CJS (no type:module), so Node16 still emits CommonJS as schematics require, while honoring exports maps. This drops the paths workaround in all three packages and needs no deprecation suppression. Add types:[node] since TS6 no longer auto-includes node ambients. * test(schematics): generate ng-add e2e fixtures inline, default to no-install collection run ng add e2e now generates the target app inline with the workspace CLI (ng new) instead of committing a fresh-scaffold fixture — self-describing and immune to fixture drift across Angular majors. Default ng add path resolves the collection from the workspace-linked package with --skip-install (the schematic under test runs fully; no package-manager step, so it can't mutate the symlinked node_modules). npm-pack tarball path kept behind useTarball:true for a future isolated-install CI. * fix(schematics): handle Angular 22 unified :unit-test runner model Angular 22 expresses Karma and Vitest as the same @angular/build:unit-test builder, distinguished by an options.runner ('karma' | 'vitest') field, rather than a dedicated :karma builder (which still exists for webpack projects). The schematics, written for the v21 model, broke on v22: - detectTestBuilder classified every :unit-test target as Vitest, so Karma on a default (esbuild) v22 app was invisible. Now it reads options.runner for :unit-test builders and keeps the :karma suffix branch for webpack projects. - jest ng-add merged {zoneless} onto the previous target's options, leaving the foreign builder's runner/buildTarget behind; the Jest builder then forwarded --runner to the Jest CLI ('Runner is not a constructor'). setBuilderForTarget gains an opt-in replaceOptions (default still merges, preserving other callers); jest ng-add uses it to start from a clean Jest option set. Surfaced by the Plan 04 ng-add e2e (ng new --test-runner karma -> ng add -> ng test). * test(jest): add Karma->Jest ng add e2e (inline fixture, real ng test) * test(jest): add Vitest->Jest ng add e2e (ng build + ng test green) * test(custom-esbuild): add build/serve rewrite ng add e2e * test(custom-esbuild): add webpack-build guard ng add e2e * test(custom-webpack): add build/serve rewrite + scaffold ng add e2e * test(jest): add @21 migration post-build smoke; fix testPathPatterns string->array The @21 migration renamed testPathPattern -> testPathPatterns but carried the value over verbatim. Jest 30's testPathPatterns is a string array, so a migrated config failed builder schema validation ('testPathPatterns must be array') at ng test. Wrap a carried-over string in an array. Surfaced by the new ng update --migrate-only post-build smoke (Plan 04 Task 6), which seeds a pre-21 config on an inline-generated app, runs the migration, then ng build + ng test. * docs(runbook): record RC-validated multi-major ng update window * test(schematics): neutralise package manager during ng add via PATH shim The ng add collection run can't use --skip-install (ng add forwards it to the schematic, whose schema rejects unknown options). Instead prepend a no-op npm/yarn/pnpm shim to PATH for the ng add spawn so the schematic's NodePackageInstallTask runs harmlessly — it cannot write through the workdir's node_modules symlink into the workspace. Every tree transform still happens; ng build/test afterwards resolve from the workspace-linked modules. * fix(custom-webpack): declare @angular-devkit/schematics and @schematics/angular deps custom-webpack's ng-add imports from both packages but didn't declare them, relying on them being present transitively via the user's @angular/cli install. Declare them explicitly (matching jest and custom-esbuild) so ng add resolves regardless of hoisting.
…isions (#1009) When running ng test in a multi-project Angular workspace, each project's coverage output was written to the same directory (e.g. root ./coverage/), causing each successive run to overwrite the previous project's coverage report. Fix: set coverageDirectory in DefaultConfigResolver.resolveForProject() to <projectRoot>/coverage so each Angular project's coverage lands in its own isolated output directory. This is a project-level default that can still be overridden per-project via the jest.config.js customization mechanism. Also removes erroneous debug console.log statements from jest-configuration-builder.ts and fixes the scopeOutputDirectoriesForProjects approach, which incorrectly mutated the Jest 'projects' array (breaking --find-related-tests and project path resolution). Adds: unit test for coverageDirectory scoping, integration test validate-coverage.js
…l integration test The unit test asserting config.coverageDirectory field value is an implementation detail check. The behavioral proof — that coverage files actually land under projects/<name>/coverage/ on disk — is covered by the integration test in validate-coverage.js. Remove the unit test to avoid false confidence from a config-shape assertion.
just-jeb
force-pushed
the
fix/1009-coverage-namespacing
branch
from
8f1c43d to
bb26223
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Checklist
PR Type
What is the current behavior?
In multi-project workspaces, all projects write Jest coverage output to the same workspace-root
coverage/directory. When projects run in sequence (ng test project-a --coverage; ng test project-b --coverage), the second run overwrites the first. There is no way to get coverage for multiple projects simultaneously.Issue Number: #1009
What is the new behavior?
coverageDirectoryis set unconditionally in the per-project default config to<projectRoot>/coverage. For a standardng newsingle-project workspace,projectRoot === workspaceRoot, so output stays at./coverage— no change. For multi-project workspaces, each project writes to its ownprojects/<name>/coveragedirectory.Users can still override via their own
jest.config.ts(the per-project user layer is merged last).Does this PR introduce a breaking change?
For library-only / non-standard workspaces where
projectRoot !== workspaceRoot, coverage output relocates from./coverageto<projectRoot>/coverage. Any tooling reading a hardcoded./coverage/path is affected. Standard single-projectng newworkspaces are unaffected. Because this is an observable behavior change, it is labeledbreaking-changeand held for the next major aligned with Angular 22 (not yet released). Will be called out in the CHANGELOG.Other information
N/A