Vitest が Jest と比較して「TypeScript や ESM（ES Modules）のプロジェクトで追加設定なしに動きやすい」と言われる最大の理由はどれですか？

解説

正解は「Vite のトランスフォームパイプラインをそのまま利用するから」です。Vitest は Vite の上に構築されたテストランナーで、テストファイルも含めてすべてのモジュールを Vite が esbuild を使って変換します。そのため、Vite で動いているプロジェクト（TypeScript、JSX、ESM、エイリアス設定など）はテスト側でも追加設定なしにそのまま動きます。他の選択肢については、Vitest は型チェックを標準では行わず（vitest --typecheck オプションで別途実行）、事前コンパイルではなくオンデマンド変換であり、Babel は内蔵していません。Jest の場合は歴史的に CommonJS 前提で作られているため、ESM や TS を使うには ts-jest や babel-jest、transform 設定などを足す必要がありました。なぜ Vite と設定を共有できると嬉しいのかフロントエンド開発では「開発サーバで動くけどテストでは動かない」というズレがよく起きます。よくある原因は、パスエイリアス（例: @/components）や、.vue・.svelte のようなカスタム拡張子、CSS Modules の扱いです。Vitest は vite.config.ts をそのまま読み込むので、一度 Vite で動かせた設定はテストでも同じ挙動になります。これが「Jest vs Vitest どっちを選ぶか」で Vite プロジェクトでは Vitest が推される最大の理由です。Jest との API 互換性についてVitest は Jest のテスト API（describe, it, expect, vi.fn など）をほぼ踏襲しています。jest.fn が vi.fn になるといった名前の違いはありますが、基本構造は同じです。import { describe, it, expect } from 'vitest' describe('sum', () => { it('adds numbers', () => { expect(1 + 2).toBe(3) }) })実務で意識したいポイントVite を使っていないプロジェクトでも Vitest は使える: ただし最大の恩恵（設定共有）は得られませんesbuild は型チェックをしない: 型エラーがあってもテストは通るので、CI では tsc --noEmit を別途走らせるのが定石ですブラウザ API が必要なら environment を jsdom に設定: DOM を扱うテストでは // @vitest-environment jsdom もしくは config で指定します「vitest なぜ速い」と検索するとよく出てきますが、速度の理由も同じく esbuild ベースの変換とワーカー並列実行にあります。仕組みを押さえておくと、ハマった時に原因の当たりをつけやすくなります。