{"id":33075,"date":"2026-04-02T17:32:55","date_gmt":"2026-04-02T15:32:55","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/migrate-from-karma-to-vitest\/"},"modified":"2026-04-03T10:14:41","modified_gmt":"2026-04-03T08:14:41","slug":"migrate-from-karma-to-vitest","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/migrate-from-karma-to-vitest\/","title":{"rendered":"Migrate from Karma To Vitest"},"content":{"rendered":"

Contents<\/strong><\/p>\n

Why Vitest instead of Karma?<\/a>
\nMore on Vitest<\/a>
\nBefore starting the migration<\/a>
\nConfirm you\u2019re using the application build system<\/a>
\nDecide on the migration strategy<\/a>
\nCheck your current behavior<\/a>
\nMigration steps for Angular CLI workspaces<\/a>
\nUpdating Angular<\/a>
\nRemove Karma<\/a>
\nInstall dependencies and adjust configs<\/a>
\nUse a custom Vitest config<\/a>
\nMigrate existing test files<\/a>
\nPrompts<\/a>
\n(Optional): Run unit tests in the browser<\/a>
\nNotes for Nx Workspaces<\/a>
\nConclusion<\/a>
\nResources<\/a><\/p>\n

<\/a><\/p>\n

Why Vitest instead of Karma?<\/h2>\n

For years, the \u201cdefault Angular testing stack\u201d meant Jasmine + Karma: Jasmine provided the test API (describe<\/code>\/it<\/code>\/expect<\/code>), while Karma acted as the runner that bundled your code and executed tests inside a real browser. That approach worked well historically, but it also accumulated friction: launching browsers is comparatively heavy, and keeping browsers available and consistent is a recurring pain point in CI environments.<\/p>\n

If you visit Karma\u2019s official GitHub page, you can read that Karma is now deprecated and does not accept new features or general bug fixes anymore.<\/p>\n

At the same time, the wider JavaScript ecosystem has shifted towards faster, more developer-friendly tooling. Vitest runs tests in a Node.js process using a DOM emulation layer (typically happy-dom<\/code> or jsdom<\/code>), so you can test DOM-oriented code without launching a browser.<\/p>\n

In late 2025, the Angular team announced that Vitest is the new default test runner for new Angular projects, and that Vitest support in the CLI is now considered \u201cstable and production-ready\u201d.<\/p>\n

Long story short: Karma is deprecated and Vitest is the future.<\/p>\n

<\/a><\/p>\n

More on Vitest<\/h2>\n

As already mentioned, Vitest typically runs in a DOM emulation layer. happy-dom<\/code> is known for its performance, while jsdom<\/code> is known for its robustness and its ability to reflect the real browser API more closely. It is still possible that certain browser APIs are not fully implemented, and you may have to add or adjust mock functions for those in your tests.<\/p>\n

It\u2019s worth mentioning that Vitest can still run in a real browser when you need it, via browser mode (e.g., using a Playwright-backed provider). In Angular\u2019s migration guide, browser mode is positioned as an optional step: you install a provider (such as @vitest\/browser-playwright) and set a browsers<\/code> option in angular.json<\/code>.<\/p>\n

The Angular team\u2019s own \u201cwhy\u201d (as stated publicly) is essentially this: modernize testing, reduce heavyweight browser coupling when it\u2019s not required, and provide a better developer experience\u2014without losing the ability to do real-browser testing when it is required.<\/p>\n

<\/a><\/p>\n

Before starting the migration<\/h2>\n

Note:<\/strong> The migration experience is still evolving. The Angular docs describe migrating an existing project to Vitest as experimental and tie it to the newer application build system. In practice, that means you should plan the migration like any other tooling change: iteratively, with a safety net.<\/p>\n

<\/a><\/p>\n

Confirm you\u2019re using the application build system<\/strong><\/h3>\n

Angular\u2019s official migration guide notes that migrating to Vitest requires the application build system, which is the default for newly created projects. Existing projects can migrate to that build system (optionally) via the documented build-system migration process.<\/p>\n

This matters because the Vitest-based unit testing integration is implemented through the newer Angular build tooling and builders.<\/p>\n

<\/a><\/p>\n

Decide on the migration strategy<\/strong><\/h3>\n

Because Angular still supports Karma\/Jasmine, you can choose between:<\/p>\n

Big-bang migration:<\/strong> convert everything to Vitest, delete Karma, done.
\nProgressive migration:<\/strong> keep Karma running while you introduce Vitest, migrate test suites over time, then remove Karma once the Vitest suite is consistently green.<\/p>\n

Progressive migration is often lower risk in real organizations, particularly for large or compliance-sensitive codebases, because it keeps a known-good runner available during refactors.<\/p>\n

If you decide to take this strategy, you have to keep the Karma npm dependencies and the config files. The config files have to be adjusted to include only the required .spec.ts<\/code> files so they do not overlap with the Vite configs. Coverage reports also have to be handled separately in this case for Karma and Vitest.<\/p>\n

<\/a><\/p>\n

Check your current behavior<\/strong><\/h3>\n

Before touching the configuration, note any Karma-specific features you rely on\u2014custom reporters, coverage thresholds, browser launchers, or polyfills injected via the Karma builder. The Angular migration guide explicitly warns that custom karma.conf.js<\/code> settings are not automatically migrated, so you should audit them before deletion.<\/p>\n

<\/a><\/p>\n

Migration steps for Angular CLI workspaces<\/h2>\n

This section generalizes the required steps to fully migrate from Karma to Vitest, which works across typical Angular CLI applications. Read through the steps carefully, and adjust them to meet your project-specific requirements if needed.<\/p>\n

<\/a><\/p>\n

Update Angular<\/strong><\/h3>\n

An update to the latest version is recommended; otherwise, the migration might get stuck on different issues. Based on the official Angular guide:<\/p>\n