Sarthak Agarwal ed2594bfd1 fix: resolve Vitest benchmarking showing wall-clock time instead of per-function timing ... Root cause: Vitest performance tests reported "20.0 seconds over 1 loop" (JUnit XML wall-clock fallback) instead of actual per-function nanosecond timing. This was a chain of two issues: 1. **stdout interception**: Vitest's default `threads` pool intercepts process.stdout.write() and console.log(), preventing timing markers from flowing to the parent process. Fixed by adding `--pool=forks` to all Vitest commands and config files. The `forks` pool uses child processes where stdout flows directly to the parent. 2. **test name detection**: Even after markers flowed through (43,000+ found in stdout), the parser couldn't match them to JUnit XML testcases because all markers had "unknown" as the test name. This happened because Vitest doesn't inject `beforeEach` as a global (unlike Jest), so capture.js's Jest-style hook to set `currentTestName` never fired. Fixed by adding Vitest-specific test name detection in capture.js: - Primary: `expect.getState().currentTestName` (full describe path) - Fallback: `__vitest_worker__.current.fullTestName` - Defense-in-depth: parser fallback matches "unknown" markers to the first testcase when no name match is found Result: cheerio's `isHtml` went from "20.0s / 1 loop" to "902μs / 20,853 loops" with proper speedup analysis. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>		2026-03-03 14:31:10 +05:30
..
codeflash	fix: resolve Vitest benchmarking showing wall-clock time instead of per-function timing	2026-03-03 14:31:10 +05:30