Jest is running in single thread, --maxWorkers does not work

[psalkowski]

Describe the Bug

The --max-workers or --maxWorkers or setting maxWorkers in angular.json, or even in jest.config.ts does not do anything. The tests are always running in single thread like --runInBand.

This have impact on:

1. Performance - we loose whole power of jest and parallel execution
2. NodeJS have bug which cause inaccurate code coverage with v8 provider (randomly drop down on some test scenarios). It happens only in single thread mode in Jest, but when running in parallel, the issue does not exist - v8 test coverage in jest is incorrect when upgrading to 20.10.0 nodejs/node#51251 (comment)

Minimal Reproduction

The simplest angular application with just jest builder with jest.config.ts having such configuration:

coverageProvider: 'v8',
collectCoverage: true,
coverageDirectory: 'coverage',
testEnvironment: 'jsdom',
coverageThreshold: {
  global: {
    branches: 100,
    functions: 100,
    lines: 100,
    statements: 100,
  },
},

Expected Behavior

We should be able to run Jest in parallel

Environment

Libs
- @angular/core version: 19.2.4
- @angular-devkit/build-angular version: @angular-devkit/build-angular
- @angular-builders/jest version: 19.0.0

For Tooling issues:
- Node version: v22.14.0
- Npm version: 11.2.0
- Platform: Mac

[just-jeb]

Thanks for reporting this! We took a close look and ran an investigation — here's what we found.

Investigation results

We were unable to reproduce the reported behavior with your exact jest.config.ts configuration.

Using your config (no maxWorkers set, coverageProvider: 'v8', collectCoverage: true, testEnvironment: 'jsdom', coverageThreshold), tests ran through @angular-builders/jest in separate worker processes — not in a single thread. We confirmed this by checking process PIDs per test file and by inspecting the resolved config via --showConfig, which reported maxWorkers: 16, runInBand: false.

There is nothing in the builder's code path that injects --runInBand or forces maxWorkers to 1.

What we think may be happening

Your evidence for single-thread execution is the Node.js v8 coverage accuracy bug, which you correctly note only manifests in single-threaded mode. However, that bug can also trigger when Jest resolves to 1 worker (not just strict --runInBand) — which happens on low-CPU machines where numCpus - 1 = 1. This could explain the symptom without angular-builders being the cause.

To move forward

Could you help us narrow it down with the following?

1. A minimal reproduction repository we can clone and run directly
2. The output of ng test --showConfig 2>&1 | grep -E '"maxWorkers"|"runInBand"' from your actual project — this shows the values Jest actually resolved, not what you configured

Without a concrete repro or diagnostic output we can't confirm this is a bug in the builder rather than an environment or configuration issue.

We'll keep this open for now, but will close it in ~1 month if we don't hear back.