Keeping a testing suite fast within a pnpm monorepo is a real technical challenge. The principle is simple: a standard set of quality tests that run routinely is much more useful than a fancy suite that takes eight minutes to finish on a local machine. If tests are too slow, developers simply won't run them.
Vitest is the right tool here since it's built on Vite. To keep your config from
clashing with the actual app, just let Vitest inherit your path aliases (like
@/ to src/) directly from your existing Vite config. Trying to create
different resolve rules for production versus testing is just a recipe for
unnecessary debugging.
Parallelism shouldn't be a guessing game, either. Don't just copy a maxWorkers
number from a tutorial. Watch your memory usage on CI. If a GitHub runner runs
out of memory because the monorepo is massive, just lower the worker count for
that specific job. You don't have to throttle performance for developers on
their local machines just to fix a CI issue.
In a monorepo, workspaces should act independently. Running pnpm test from the
root can trigger everything, but every package needs its own specific config. A
UI package doesn't need heavy Next.js plugins, and pure logic packages like
billing are fine with environment: 'node'. Forcing every single package to
use jsdom just adds unnecessary cost to your runtime.
Watch your setup files, too; don't let them become a configuration junk drawer. While it's common to put MSW there for network mocking, try not to pile in timer mocks, routers, and analytics all in one giant file. This much clutter leads to flaky tests—tests that fail inconsistently—because global states start bumping into each other.
Finally, don't get obsessed with code coverage numbers. Coverage reports are optional. Don't let a deployment get blocked just because your percentage dropped slightly due to a documentation file or a story. Focus on whether the tests are actually useful, rather than just chasing a number on a dashboard.
Back to the editor.