Skip to content

Build1 publisherNot yet confirmed elsewhere3 min readPublished

Miro moved 70,000 tests from Jest to Vitest after years of slow CI, memory leaks, and failed patches

Miro moved 70,000 unit tests on its 6-million-line frontend from Jest to Vitest in two months, one of its engineers wrote. His figures for the old CI, six runners at up to 20 minutes a job, show what another team's test jobs would have to look like before the same switch pays off.

The Engineer · Build desk

How we use AISend a correction

Illustration accompanying Miro moved 70,000 tests from Jest to Vitest after years of slow CI, memory leaks, and failed patches
Generated illustration

What happened

  • In July 2024 the team chose not to switch, when 35,000 tests ran across six runners in about seven minutes each.
  • In March 2025 duplicate fb-watchman installs from the VSCode Jest extension saturated engineers' laptop CPUs until the team set watchman: false.
  • By early 2026 the yarn and NX monorepo held more than 800 packages, and the unit-test count had doubled in two years.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • cost At the 20-minute ceiling each pipeline spends up to 120 runner-minutes on unit tests, and a run killed by memory exhaustion returns no result for that spend.
  • constraint With Jest 30 recovering about 5% and Miro's worker-pool patches refused upstream, staying on Jest meant Miro carried its own fixes through every future upgrade.
  • decision The same team judged test selection the better bet at half the test count, so a smaller suite has to price both options before copying the switch.

If Jest's 13 tests per second is a per-runner rate, the post's two CI figures agree with each other. Seventy thousand tests split across six runners is about 11,700 per runner [19]. At 13 a second that comes to roughly 900 seconds, or 15 minutes [20]. The author gives a ceiling of 20 minutes per runner [4]. On that reading, most of each job is Jest running tests, with SWC already doing the parsing [5].

The suite also got slower faster than it grew. In July 2024, six runners took around 7 minutes each for 35,000 tests [12]. The count then doubled to about 70,000 [17] while the per-runner ceiling rose about 2.9 times [21]. One figure is "around" and the other "up to", so the ratio is loose. I'd expect that shape from memory piling up in long-lived workers, and the post says a quarter of all runs fail because leaks kill runners with out-of-memory errors [6].

The earlier refusals were sound for their time. In November 2023 a colleague wrote that "the extra set of vitest specific configurations and replicating our current build might be too risky, without knowing how much speed benefits we get now that we're relying on @swc/jest" [9]. The team had just started running unit tests in parallel and was buying back wall time with extra runners, an approach that "Worked pretty well", Sergey wrote [10]. In July 2024 another colleague wrote: "I expect higher returns from better test selection (e.g. not running 35k unit tests each time). The cost of switching to vitest (for example) is high and unclear what the improvement is" [11].

Waiting for Jest to improve did not pay. The move from Jest 29 to Jest 30, the first major release in three years, gave about 5% on speed and memory [8]. Miro had already patched Jest core packages to get a better worker pool, and those patches were never accepted upstream [7].

Laptops broke as well. In March 2025 the VSCode Jest extension installed several versions of fb-watchman, Jest's filesystem watcher, and saturated engineers' CPUs until the team set `watchman: false` [13]. Ahmed, a principal engineer on the team, said: "I want to say maybe it's time to switch to vitest, but that's a massive effort..." [14]. Sergey had no capacity to lead it then, and with AI models getting better at complex problems, "All signs were to wait for a bit" [15].

The two-month duration is Sergey's claim, made in the post's headline [1]. The excerpt ends before the migration plan and the after-migration timings, so the duration is the only result on record. The starting state is specific. A dedicated Frontend Developer Experience team owns the tooling [2]. The monorepo runs on yarn and NX across more than 800 packages [16]. In the same year that group replaced Prettier with Oxfmt and ESLint with Oxlint, and moved CI typechecking to TypeScript 7 [18]. A team running 35,000 tests in seven-minute jobs is where Miro stood when a colleague argued for test selection over a switch [11] [12].

What to watch

  • Miro publishing Vitest-era runner times and out-of-memory failure rates, which would show whether two months of work bought speed, stability, or both.
  • Whether the migration method leaned on AI-assisted code changes, the reason the author gave for waiting, since that decides how far the two-month figure transfers to teams without the same tooling.
  • Whether Miro publishes its Vitest configuration for the 800-package NX monorepo, the setup a 2023 colleague called the main risk.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence40
Adoption30
Hype gap+20
Incentives35
Confidence45
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Miro migrated about 70,000 unit tests from Jest to Vitest in two months.

    ReportedSupportedSource: Sergey, Miro Frontend Developer Experience engineer, dev.to post headlineView cited source
  2. [2]

    The author, Sergey, is a software engineer in Miro's Frontend Developer Experience team, which owns frontend infrastructure and tooling.

    ReportedSupportedView cited source
  3. [3]

    The main Miro application is about 6 million lines of code.

    ReportedSupportedView cited source

Sources

1 independent publisher whose own reporting we read for this story.

  1. dev.to

    1 article · October 8, 2026

    We migrated 70,000 tests from Jest to Vitest. Yes, in 2 months

Share your take

Let Clarity write the post for you.

Signed-in readers get a short post drafted on this story in the register they choose — narrative, analytical, or a direct position — editable to the last word before it goes anywhere. The share buttons at the top of this story work without an account.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Loading related stories