chore: migrate test runner from Jest to Vitest#6937
chore: migrate test runner from Jest to Vitest#6937FabienMotte wants to merge 31 commits intomasterfrom
Conversation
fce176c to
71ed792
Compare
More templates
algoliasearch-helper
instantsearch-ui-components
instantsearch.css
instantsearch.js
react-instantsearch
react-instantsearch-core
react-instantsearch-nextjs
react-instantsearch-router-nextjs
vue-instantsearch
commit: |
…MatchNormalizedSnapshot
The `execSync` call in the install test takes longer than Vitest's default 5000ms timeout.
Replace jscodeshift's `defineTest` (which uses CJS `require()` to load .ts transforms) with `applyTransform` + ESM imports. Remove codemod and transform exclusions from vitest.config.ts so all tests run in the main suite.
|
what was missing to finish this @FabienMotte? seems like the CI was green before rebase |
Just missing some reviews, I'll mark it as ready and solve the conflicts |
|
I also see the timing is almost exactly the same. Is that something that can be fixed? otherwise I'm not sure if there's much value? |
I agree, I tried multiple solutions to reduce the test's duration, but ultimately, it still takes more time. Should we close it for now and revisit it later? |
|
yes, let's stay with jest for now then. Thanks for the exploration though! |
Summary
Migrate the entire monorepo test runner from Jest 27 to Vitest 4. This eliminates the Babel dependency for tests, leverages Vite's native ESM/TypeScript/JSX handling, and modernizes the test infrastructure.
Core migration
jest.config.jswithvitest.config.tsat root level and in subpackages (algoliasearch-helper,create-instantsearch-app)jest.*→vi.*replacements across all test files (~1400+vi.fn(),vi.mock(),vi.spyOn(), etc.)jest.requireActual()(sync) →await vi.importActual()(async) in all mock factories@jest-environmentpragmas with@vitest-environmentacross ~200 test filestoWarnDev,toMatchNormalizedInlineSnapshot, Vue matchers) to Vitest types and APIsdone()callback patterns toreturn new Promise()wrapper (deprecated in Vitest)jest-environment-jsdomcustom environment with Vitest's built-in jsdom (Node 20 provides all needed globals natively)Subpackage migrations
test/run.jsto usestartVitest()API instead ofjest.runCLI()"type": "module"), add dual exports (index.js+index.cjs) for backwards compatibility, rename template configs from.template.js→.template.cjs, add.template.jsfallback for custom templatesConfiguration updates
"types": ["vitest/globals"], remove@types/jesteslint-plugin-jestwitheslint-plugin-vitest, update all rule references.circleci/config.ymlfor Vitest commands and JUnit output paths@vitejs/plugin-vue2) and Vue 3 (@vitejs/plugin-vue) via env var switchingPerformance optimizations
Vitest 4 compatibility fixes
Mocktype params, implicitany, and spread arg errors for Vitest 4Mock,MockInstance,MockedFunctiontypes fromvitestinstead of relying on globalsvi.fn()type args (removed in Vitest 4), remove unused importsvite@8to root devDependencies for correct type resolutionVue 3 fixes
Codemod test migration
instantsearch-codemods,instantsearch.js/scripts/transforms) to Vitestjscodeshift/dist/testUtils.defineTest(which uses CJSrequire()for transforms) withapplyTransform+ ESM importsvitest.config.tsso all tests run in the main suiteBug fixes along the way
dispose(), incorrect Promise constructors, etc.)jsdom-global,babel-eslint)__self/__sourceattributes breaking snapshots and accessible name assertionsCleanup
Benchmarks
Local
Local benchmarks on Apple Silicon via
yarn test(wall-clock time, no coverage).master)Vitest wall-clock time is higher locally due to Vite's module transformation and environment setup overhead. The tradeoff is eliminating the Babel transpilation pipeline, gaining native ESM/TypeScript/JSX support, and modernizing the DX (HMR watch mode, better error formatting, native coverage via v8).
CircleCI
Recent CircleCI
unit testsjob runs on this branch are more stable and faster on rolling metrics thanmaster.master)The latest single run is noisy, but the last-5 median is about 17s faster on this branch and the last-5 average is about 47s faster (-14.3%). Some longer
masterruns are likely inflated by flaky tests being retried, which makes the branch's tighter timing range a better signal than any one-off run.Test plan
algoliasearch-helpertests pass (95 test files, 445 tests)create-instantsearch-apptests pass (10 test files, 74 tests)yarn lintpassesvitest/globalstypes