Confession: I tried to migrate a client app from Jest to Vitest in late 2024, gave up after a weekend, and went back to my Jest config. Then in January 2025 I tried again on a fresh Next.js project and finished the whole switch in about an hour. Two years later, every new project I start uses Vitest, and I’ve quietly migrated four of the six client apps I still maintain.<\/p>\n
So this post is the version of the answer I wish I’d had in 2024. Where Vitest actually wins. Where Jest still beats it. The real reason I switched (it isn’t speed). And the migration playbook I now run on every project, which takes about a week of part-time work.<\/p>\n
If you’re impatient: use Vitest for anything new, and migrate Jest projects when you’re already touching the test config for another reason. Don’t migrate just because Twitter says you should.<\/p>\n
The thing that finally pushed me wasn’t a benchmark. It was an Vitest, meanwhile, just works with the Vite config I already have. No Babel. No That’s the headline. Speed is the marketing copy. Config simplicity is the actual reason most people switch and stay switched.<\/p>\n The benchmarks people share online are a bit misleading. On a small project (under 50 test files), I can’t reliably tell the difference. Both runners boot in a second or two and finish a unit suite before I’ve stopped typing.<\/p>\n The gap shows up in two specific situations. First, watch mode on big monorepos. On a roughly 800-test suite I have at work, Jest’s watch mode takes around 9 seconds to react after a file save. Vitest takes about 2. Multiply that by every TDD loop and the productivity difference is real.<\/p>\n Second, cold starts in CI. Jest spends a chunk of its boot time on Babel transforming everything. Vitest reuses Vite’s pre-bundled deps, so the cold start on a fresh CI runner is consistently 30 to 50% faster in my pipelines.<\/p>\n If your project is small and you only run tests in a flat one-shot CI command, you won’t notice. Don’t switch just for speed.<\/p>\n This is where the difference is hard to argue with. Here’s a Jest config from a Next.js 14 project I migrated last year, after years of accreted plumbing:<\/p>\n The Vitest equivalent on the same project looks like this:<\/p>\n Path aliases come from That config has been stable for over a year now. The Jest one I had to revisit roughly every quarter.<\/p>\n Here’s the thing nobody puts in the marketing: Jest’s ESM support has been “experimental” since 2021, and as of mid-2026 it still is. You can read the open ESM tracking issue on the Jest repo<\/a> for yourself. It’s the kind of issue that makes you close the tab.<\/p>\n The practical pain shows up when a dependency you didn’t choose ships ESM-only. Jose did it. Several @octokit packages did it. node-fetch v3 did it. Each time, you end up adding more entries to Vitest sidesteps this by being ESM-native. Modules are loaded the same way the rest of your app loads them in development. When If your project has zero ESM dependencies, this won’t matter to you. But it’s been about three years since I started a project where that was true.<\/p>\n I want to be fair here. Vitest has a few real ergonomic regressions versus Jest, and the biggest is module mocking.<\/p>\n Jest’s The first time I hit this I lost 20 minutes to a confusing error. Now it’s muscle memory. But Jest’s version was, all told, friendlier to read and easier to teach to a junior engineer.<\/p>\n Snapshot testing also still feels slightly more polished in Jest. Vitest has parity for the basics, but the inline snapshot UX in Three cases where I haven’t migrated, and probably won’t.<\/p>\n A legacy Express app I maintain has roughly 1,200 tests, half of which use deeply nested A React Native app where Jest is the default and the entire RN testing ecosystem assumes it. Vitest can technically run there now, but most RN-specific testing libraries still ship with Jest in their docs. I’m not interested in being the team that figures it out first.<\/p>\n And one client project where the senior engineer has strong opinions and zero appetite for tooling changes. Pick your battles.<\/p>\n If you decide to migrate, here’s the rough plan I follow now. Spread across a week, in roughly half-hour chunks, it’s almost painless. (When I tried to do it in a weekend in 2024, I burned out by Saturday afternoon.)<\/p>\n Day 1.<\/strong> Install Day 2.<\/strong> Run a single test file under Vitest. Fix imports as needed. About 90% of Day 3.<\/strong> Convert your Day 4.<\/strong> Replace Day 5.<\/strong> Update CI. Replace Day 6.<\/strong> Run the suite five times in CI. Watch for flakes. The handful I’ve seen in real migrations have always been pre-existing race conditions that Jest happened to mask with its slower scheduling.<\/p>\n Day 7.<\/strong> Delete For a Next.js or Vite app, this whole sequence usually takes me under two hours of focused work. For an old CRA app or a complex monorepo, more like a full day.<\/p>\n One concrete action for this week: take your slowest test file in Jest, copy it into a fresh Vitest setup, and just see how it feels. You’ll know in ten minutes whether the rest of the migration is worth your time. The official Vitest migration guide<\/a> covers the full API mapping if you want a checklist. And if you want the broader runtime context for why testing infra has shifted so much in the last two years, my Bun vs Node piece from earlier this month<\/a> covers what’s running tests in production for me right now.<\/p>\n If you’re picking a stack from scratch in 2026, use Vitest. If you’ve already got a healthy Jest setup that nobody complains about, leave it. The best migration is the one you do because the friction is real, not because the tooling discourse is loud. Most of what I post about this kind of judgement-call work lives on my portfolio site<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" I’ve been migrating projects from Jest to Vitest since late 2024. Here’s where Vitest actually wins, where Jest still beats it, and the playbook I use.<\/p>\n","protected":false},"author":2,"featured_media":179,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"I've been migrating projects from Jest to Vitest since late 2024. Here's where Vitest actually wins, where Jest still beats it, and the playbook I use.","rank_math_focus_keyword":"vitest vs jest","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[165,197],"tags":[44,199,30,201,63,200,198],"class_list":["post-180","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-javascript","category-testing","tag-javascript","tag-jest","tag-testing","tag-tooling","tag-typescript","tag-vite","tag-vitest"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/180","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=180"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/180\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/179"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=180"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=180"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=180"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}npm audit<\/code> on a Next.js 14 app. Jest had pulled in a chain of @babel\/*<\/code> packages I didn’t directly need, half of them flagged for transitive vulnerabilities. I went to upgrade Jest, hit an ESM-related config error, spent two hours reading GitHub issues, and realised I’d had this exact conversation with myself before.<\/p>\ntransformIgnorePatterns<\/code> hieroglyphics. No moduleNameMapper<\/code> ten lines deep. The test runner runs the same transformer my dev server uses, which means if it loads in dev, it loads in tests.<\/p>\nSpeed: where the gap actually shows up<\/h2>\n
The config: 60 lines to 4<\/h2>\n
\/\/ jest.config.js\nconst nextJest = require('next\/jest')\n\nconst createJestConfig = nextJest({ dir: '.\/' })\n\nconst customJestConfig = {\n setupFilesAfterEach: ['<rootDir>\/jest.setup.ts'],\n testEnvironment: 'jest-environment-jsdom',\n moduleNameMapper: {\n '^@\/(.*)$': '<rootDir>\/$1',\n '^.+\\\\.(css|less|scss)$': 'identity-obj-proxy',\n '^.+\\\\.(svg)$': '<rootDir>\/__mocks__\/svg.js',\n },\n transformIgnorePatterns: [\n '\/node_modules\/(?!(jose|@panva|openid-client|oauth4webapi)\/)',\n ],\n testPathIgnorePatterns: ['\/node_modules\/', '\/.next\/', '\/e2e\/'],\n collectCoverageFrom: [\n 'app\/**\/*.{ts,tsx}',\n 'components\/**\/*.{ts,tsx}',\n '!**\/*.d.ts',\n ],\n}\n\nmodule.exports = createJestConfig(customJestConfig)\n<\/code><\/pre>\n\/\/ vitest.config.ts\nimport { defineConfig } from 'vitest\/config'\nimport react from '@vitejs\/plugin-react'\nimport tsconfigPaths from 'vite-tsconfig-paths'\n\nexport default defineConfig({\n plugins: [react(), tsconfigPaths()],\n test: {\n environment: 'jsdom',\n setupFiles: ['.\/vitest.setup.ts'],\n },\n})\n<\/code><\/pre>\ntsconfig.json<\/code> automatically through vite-tsconfig-paths<\/code>. CSS imports are handled by Vite. The Jose\/OIDC dance from transformIgnorePatterns<\/code> doesn’t exist because Vitest treats those packages as ESM correctly the first time.<\/p>\nESM was the real reason<\/h2>\n
transformIgnorePatterns<\/code> until the config is effectively a list of every modern package on npm.<\/p>\njose<\/code> ships a new ESM-only release, my tests don’t break. They just run.<\/p>\nMocking: where Jest still feels nicer<\/h2>\n
jest.mock('.\/foo')<\/code> call is hoisted by Babel automatically, which is convenient and slightly magical. You can write the mock anywhere in the file and it works. Vitest’s vi.mock()<\/code> is also hoisted, but the rules are stricter. You can’t reference variables defined in the test file inside the factory function unless you wrap them in vi.hoisted()<\/code>:<\/p>\n\/\/ This won't work in Vitest:\nconst fakeUser = { id: 1, name: 'Alice' }\nvi.mock('.\/auth', () => ({\n getUser: () => fakeUser, \/\/ ReferenceError at hoist time\n}))\n\n\/\/ You have to do this:\nconst { fakeUser } = vi.hoisted(() => ({\n fakeUser: { id: 1, name: 'Alice' },\n}))\nvi.mock('.\/auth', () => ({\n getUser: () => fakeUser,\n}))\n<\/code><\/pre>\n--update<\/code> mode trips me up about once a month.<\/p>\nWhen I still keep Jest<\/h2>\n
jest.mock<\/code> calls and require contexts. Migrating it is a week of work for a project that gets one PR a month. The math doesn’t work.<\/p>\nMy one-week migration playbook<\/h2>\n
vitest<\/code>, @vitest\/coverage-v8<\/code>, and any environment package you need (jsdom<\/code> or happy-dom<\/code>). Write a minimal vitest.config.ts<\/code>. Don’t touch any tests yet. Run vitest run __nothing__<\/code> just to confirm the runner boots.<\/p>\nimport { describe, it, expect } from '@jest\/globals'<\/code> lines need to become from 'vitest'<\/code> (or you can set globals: true<\/code> in the config and remove the imports entirely, which is what I now do).<\/p>\njest.mock<\/code> calls to vi.mock<\/code> and add vi.hoisted()<\/code> where you reference outer variables. This is the most error-prone step. Do it in batches and run the suite between each batch.<\/p>\njest.fn()<\/code> with vi.fn()<\/code>, jest.spyOn()<\/code> with vi.spyOn()<\/code>, etc. The find-and-replace is mostly mechanical. ESLint rules from eslint-plugin-vitest<\/code> catch the rest.<\/p>\njest --ci<\/code> with vitest run --reporter=verbose<\/code>. If you collect coverage, swap the coverage command. Delete jest.config.js<\/code>, jest.setup.ts<\/code>, and the entire babel.config.js<\/code> if you only kept it for Jest.<\/p>\njest<\/code>, babel-jest<\/code>, and the rest of the Jest dependency tree from package.json<\/code>. Run npm dedupe<\/code>. Smile a little at the size of the diff.<\/p>\n