import-cycle-lint.test.ts can time out under a loaded full-suite run #420

packages/cli/test/import-cycle-lint.test.ts › "reports a value cycle written into packages/cli/src" failed once in a full pnpm vitest run. It took 22.2s, past the suite's 20s testTimeout (packages/cli/vite.config.ts). I didn't capture the error text.

Run alone, the same test takes about 1.1–1.5s over three runs (2 tests, ~3s wall clock). A rerun of the full suite passed, and so did the file on its own. A second full-suite failure during the #414 review looks like the same flake, but which test failed wasn't recorded.

Likely cause

The test runs ESLint with the repository's real eslint.config.js, which uses type-aware linting (parserOptions.projectService: true). Linting the two fixture files therefore builds a TypeScript program for the project. That's CPU-heavy, and a loaded full run has every vitest worker competing for CPU, many of them spawning the built CLI. vite.config.ts documents the same mechanism behind the earlier 5s → 20s timeout raise. This test gets 15–20× slower under that load, which is enough to cross 20s.

The test also writes its fixture into packages/cli/src on purpose (__cycle-guard-*), so that the rule is proven to reach that tree. That's unrelated to the timeout, but it's worth keeping in mind for any fix that moves the fixture.

Options

• Give this test its own, larger timeout (it(..., 60_000)), since it's the one test that builds a TS program in-process.
• Or run it outside the parallel pool (a separate vitest project, or describe.sequential in a file excluded from the parallel run).
• Or lint the fixture with type-aware parsing turned off through overrideConfig, provided import-x/no-cycle still resolves .ts imports. That's what the test exists to prove, so this needs checking against the failure mode described in its header.

Found while landing review fixes on the 0.12.0 stack (#411–#416). The test is unrelated to that stack's changes.