My team's experience switching from vue-cli to vite and jest to vitest

At Lob we recently migrated from vue-cli to vite as our build and development tooling and from jest to vitest for our unit testing framework.

Motivation to update to vite

1. We had recently updated vue-cli to fix a security vulnerability that had been introduced into a package dependency of vue-cli. That update led us to a place where certain package dependencies couldn’t be updated to the latest without encountering strange and hard to debug errors/issues
2. vite is now the official build tool recommended by vue.js and documented in their setup/installation instructions
3. tests were incredibly slow to run and it was hoped that vite and/or vitest would help speed them up
4. Vite is not based on Webpack and has its own dev server which utilizes native ES modules in the browser. This architecture allows it to be orders of magnitude faster than Webpack’s dev server. Vite employs Rollup for the build, which is faster as well.
5. The approach also means that Hot Module Replacement remains fast no matter the size of the application since the entire bundle doesn’t have to be reconstructed.
6. In a larger project, the difference becomes even more impressive. The Webpack dev server may slow down to 25-30sec for a build/re-build, or sometimes even more. The Vite dev server, meanwhile, may be able to serve the same project at a constant 250ms speed.

Motivation to update to vitest

1. Jest, the testing framework we were using prior, does not work out of the box with vite. There is a plugin library still in development and is very much still a work in progress.
2. Jest represents a duplication of complexity. If your app is powered by Vite, having two different pipelines to configure and maintain is not justifiable. With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same vite.config.js.
3. Vitest gives you a faster run for your unit tests and a jump in DX thanks to the default watch mode using Vite instant Hot Module Reload (HMR).
4. The API differences between vitest and Jest are close to none (self-described as “drop-in replacement”) so the migration path looked very simple.

The positive

The following details metrics taken before and after the migrations:

• running the dev server went from (23, 19, 20)s to (342, 252, 247)ms
• HMR went from (3241, 974, 885, 581, 716)ms to essentially instant
• running the build went from (35, 33, 34)s to (17, 19, 18)s
• running the test suite went from (5m 33s, 5m 47s, 6m) to (9m 23s, 8m 34s, 8m 17s)

So vite is fast!

In addition to the amazing speed boosts we’ve gotten from using vite for building and the dev server, we’ve gotten a couple new features that we’ve really appreciated:

1. There’s now an option to preview the production build separately from the dev build on the local dev server.
2. Additionally, the vitest watcher watches for changes in files (based on filter string provided to the command) and re-runs tests on those files (you can re-run all tests or just the tests that failed previously) and it’s fast.

The negative

The migration experience was not as easy or as straightforward as I was expecting.

I broke the CSS compiling so that none of the style blocks in components were being included in the resulting CSS for the app. It turned out I had set in the vite.config the following: I did this while troubleshooting something totally unrelated and didn’t need the setting at all in the end. Removing the setting allowed CSS compilation to execute correctly again.

plugins: [ vue({ customElement: true }) ],

On the vitest side of the migration, it turned out that lot’s of tests fail with vitest that worked fine before with Jest:

1. mocking things needed to be updated
   1. mocking a module that has a default export is done differently in vitest
2. router.push and router.isReady() seem to cause problems
3. mocking the router versus spying causes issues
4. error messages are not helpful in determining what is causing the test to fail and how to fix
   1. TypeError: Cannot destructure property 'type' of 'vnode' as it is null. seems to happen when we use router.isReady() when the route hasn’t been changed
   2. TypeError: Cannot read property 'tagName' of null seems to happen when an element is not yet in the DOM when we try to take an action (fireEvent or userEvent on it)
5. elements that get dynamically rendered after some event seem to take longer and need to use methods that await before they can be queried or acted upon whereas before that wasn’t needed

Conclusion

The bonus/side effect of having to do the test clean up was that it actually forced us to clean up things that were unnecessary or not best practice. The code in the tests is simpler and more clear. Previously we were doing things we didn’t need to be or repeating bad patterns and this forced us to clean them up.

Even though the migration process was not the most smooth for us, this could totally be as a result of unique things in our application and not a reflection of migrating any app from vue-cli to vite or jest to vitest. I still believe these are amazing tools and well worth any challenges in migrating. Both vite and vitest are being updated constantly and have amazing support. I highly recommend that all new Vue projects use these tools and that even well established apps consider making the switch in the near future.