We migrated our web app’s codebase from Webpack 4 to Vite for one simple reason: speed 🏃🏃🏃.

Since Vite is relatively new, we can share that it’s stable and has made a tremendous difference in our lives as developers. Plus, the move was straightforward and didn’t take long—though our team here at Swimm learned some hard lessons along the way.

Here’s a bit more about why we made the switch in the first place.

What is Vite?

Vite is a Javascript build tool designed for speed. Vite consists of two major parts: a dev server that uses native ES modules that makes Hot Module Replacement incredibly faster, and a build command that uses Rollup behind the scenes.

Why we decided to migrate from Webpack

We used Webpack 4 at Swimm for over two years as it’s used in Vue CLI, which is the service we use for our app’s client-side. But about six months ago, we decided we needed to change when Webpack slowed us down as our codebase expanded and became more complex.

Though Webpack 5 has been available for a couple of years, migrating Vue CLI from v4 to v5 introduced several breaking changes that made the migration quite challenging.

Webpack’s performance was a deal breaker
Webpack’s Hot Module Replacement (HMR) works well until you have too many files in your codebase. As our web app became larger and larger and we had many files in the codebase, it made HMR so slow it would sometimes break.

• Launching Webpack for local development took upwards of two minutes at best.
• HMR in Webpack took about 10 seconds.

Moving from Webpack to Vite: the challenges

The entire move to Vite took just a couple of days. Most of the work was done in one day by four devs, with some pre-work done in the days prior.

While we were able to migrate quickly, we had to overcome some technical difficulties right off the bat.

Project separation
First off, our codebase needed some restructuring.

Swimm has several projects in addition to the web app including IDE plugins and Swimm’s GitHub app, and Webpack’s configuration was relevant for most of them. Because Vite is intended for web projects, we had to extract the shared code between the projects so that the web app would be isolated and independent.

Environment variables and configuration files
Second, we had to clean up our environment variables and config files including tokens, URLs, and .env files. In particular, our TypeScript and eslint configuration had to be readjusted.

Also, environments in Vite are handled very differently than in Webpack. Specifically, Vite has its own set of defaults and a new namespace. We imagine that other dev teams, like us, will need to go through extensive migration and configuration change work to work within Vite’s environmental expectations.

Using Swimm to Migrate to Vite

There were many code changes during the process of migrating from Webpack to Vite. No surprises there.

And since all of our code is documented in Swimm, this meant that we were able to ensure that our docs stayed up to date, current, and relevant. And, of course, we had a place to put all of the items we didn’t want to forget about the migration.

So, in addition to the Swimm documentation connected to the code changes, we also now have a “How We Use Vite doc” for our team at Swimm to read and use as we continue to ease into the migration.

Moving to Vite: the easy wins

Once the challenges for the migration were behind us, we saw the Vite wins immediately.

Speed
No matter how big the project size is in development mode, it doesn't impact Vite’s speed.

• Vite launches in less than one second (~700 milliseconds).
• HMR in Vite takes less than one second.

Native integrations and efficiency
Vite was written by the same developers as Vue, so we gained from a lot of the native integrations and synergies between the two. Vite also uses esbuild and doesn’t require bundling in pre-production environments, which makes local development so fast. It’s orders of magnitude faster than using Webpack. Also, Vite only supports modern browsers, so there’s no additional code to support legacy browsers many dev teams aren’t using.

But you don’t have to use Vue with Vite. Vite is completely separate so you can use it with React, Angular, and others however they best fit your project needs. Vite also has a lot of official plugins and many more community plugins.

Other technical details

A few other points to keep in mind if you’re considering migrating from Webpack to Vite:

• Shims and Polyfills. Unlike Webpack 4 and earlier versions, you don’t get any automatic shims or polyfills for Node.JS modules with Vite. So, support for older mixed Node.JS/Browser modules can be a bit difficult. You can’t easily import anything and just expect it to work. And if you have some legacy Node.JS module that’s mission-critical, it will present challenges you’ll need to consider.

• Bundling. When it comes to bundling, Vite is a general solution that does things a little differently. It’s not just a file watcher, web server, and bundler; it does on-demand compilation. As a browser requests updated JS files, Vite delivers them live and just in time. It’s super fast because of esbuild. There’s no need for complicated bundler solutions, and it only replaces the changed file via HMR.

• Project configuration.Project configuration is also something to watch out for. We had all sorts of issues with templates and had to go deep into the documentation. We recommend you stick to configuration defaults and templates if you can and only change the configuration if you know what you’re doing.

Bottom Line

Migrating from Webpack to Vite was well worth it, and we are very happy with the results. The migration from Webpack to Vite may present some challenges if your code repository has shared resources and dependencies across projects. But if your code is well isolated and independent, you’ll hopefully have an easy time with it.

We think the migration to Vite is well worth the investment if Webpack has slowed you down.