fix(@angular/build): prevent unit-test vitest runner from hanging after tests complete

[hebus]

PR Checklist

• The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

• Bugfix

What is the current behavior?

In non-watch mode, ng test with the vitest runner hangs indefinitely after all tests
complete and results are printed. The executor disposes the Vitest instance with
close(), which has no teardown timeout. Whether the hang occurs depends on the size
of the TypeScript program of the spec tsconfig (full analysis in the linked issue) —
freshly generated projects exit cleanly while larger real-world projects hang on every
run, leaving orphaned node/esbuild processes in CI.

Issue Number: #32832 (likely also #33317)

What is the new behavior?

When not in watch mode, the executor calls vitest.exit() instead of vitest.close(),
mirroring what the vitest run CLI does: exit() arms an unref'd teardownTimeout
safety net (process.exit() after 10s by default) before closing. When teardown
completes normally nothing changes; when something keeps the event loop alive, vitest
reports it and force-exits:

close timed out after 10000ms
Tests closed successfully but something prevents the main process from exiting

Watch mode still uses close() and is unaffected.

Validated on a project that reproduces the hang on 100% of runs (315 tests, 19 spec files):

• run mode, passing tests: process now exits on its own, exit code 0
• run mode, failing tests: exit code 1 preserved
• watch mode: process stays alive, re-runs on change
• no orphaned node/esbuild processes after the run

Does this PR introduce a breaking change?

• No

Other information

No test added: asserting "the process exits" requires a real hanging handle, which the
builder test harness does not reproduce (small programs tear down cleanly — that is the
bug's timing dependency). Happy to add one if there is a suitable seam.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request updates the VitestExecutor disposal logic to call vitest.exit() instead of vitest.close() in non-watch mode, preventing hanging processes. The review feedback recommends adding a defensive check to verify that vitest.exit is a function before calling it, and warns that calling exit() could prematurely terminate the host process when executed programmatically.

[gemini-code-assist]

1. Defensive Programming Check

Since vitest is a dependency that might be resolved to different versions in user workspaces, it is safer to defensively check if exit is a function before calling it to prevent runtime TypeError exceptions.

2. Programmatic Execution & process.exit() Side-Effects

Calling vitest.exit() arms a teardown timeout that eventually calls process.exit(). While this successfully prevents hanging in standard CLI runs, it can be problematic when the builder is executed programmatically (for example, via the Architect API in custom scripts, monorepo tools like Nx, or IDE integrations). In those cases, abruptly calling process.exit() will terminate the entire host process, preventing subsequent tasks or cleanup from running.

Consider adding a defensive check for typeof this.vitest.exit === 'function', and potentially exposing a way to opt-out of the force-exit behavior if run programmatically.

Suggested change

	if (this.vitest && !this.options.watch) {
	// In run (non-watch) mode, mirror the `vitest run` CLI by using `exit()`, which arms an
	// unref'd `teardownTimeout` safety net (`process.exit()`) before closing. `close()` alone
	// can wait indefinitely when a worker or service keeps the event loop alive, leaving the
	// process hanging after all tests have completed.
	// See https://github.com/angular/angular-cli/issues/32832
	await this.vitest.exit();
	} else {
	await this.vitest?.close();
	}
	if (this.vitest && !this.options.watch && typeof this.vitest.exit === 'function') {
	// In run (non-watch) mode, mirror the `vitest run` CLI by using `exit()`, which arms an
	// unref'd `teardownTimeout` safety net (`process.exit()`) before closing. `close()` alone
	// can wait indefinitely when a worker or service keeps the event loop alive, leaving the
	// process hanging after all tests have completed.
	// See https://github.com/angular/angular-cli/issues/32832
	await this.vitest.exit();
	} else {
	await this.vitest?.close();
	}

[hebus]

Thanks for the review. Responding to both points:

1. Defensive typeof check — declined for consistency: this file already calls other Vitest instance methods (close(), start(), invalidateFile()) without runtime guards. exit() is long-standing public API on the Vitest class — it is what the vitest run CLI itself calls on shutdown — covered by the package's vitest peer range and type-checked via the Vitest type from vitest/node.

2. process.exit() side-effects in programmatic execution — this trade-off was weighed when preparing the change. The key property of exit() is that its teardownTimeout safety net only fires in the pathological case where close() would never settle; in every healthy teardown, exit() and close() behave identically and process.exit() is never invoked. Comparing the scenarios:

• CLI runs (the common case, and where @angular/build:unit-test vitest executor hangs indefinitely — uses close() instead of exit() #32832 is reported): infinite hang → bounded exit.
• One-shot programmatic hosts hitting the hang: the host currently hangs forever as well; with this change it terminates after completing its work.
• Long-lived in-process hosts (daemons) hitting the hang: the only scenario that regresses — the daemon previously survived with leaked handles and would now be terminated after teardownTimeout. Runners like Nx and IDE integrations typically execute builders in dedicated forked processes, which narrows this further.

If the maintainers consider the daemon scenario blocking, happy to gate this (e.g. only arm the safety net when the builder owns the process, or behind an option) — though that would give up protection precisely where most users hit #32832.