From Webpack/Jest to Vite/Vitest: Data-Driven Approach

Technology migration must be data-driven, not trend-driven. Today, many organizations are considering moving from Webpack to Vite as a build tool, and from Jest to Vitest as their test environment. But what are the strong arguments for making this leap, especially from a Data Driven Development (DDD) perspective?

npm trends graph: vite vs webpack

Why Migrate: Beyond Intuition, Let the Data Speak

Data-driven development means making technical choices based on facts, metrics, and measurable results. It relies on evidence, not just feelings or personal likes. In this sense, migrating from Webpack/Jest to Vite/Vitest can be justified by the following observable data and trends:

• Speed and Productivity: Vite shines with its quick startup and almost instant hot reload. This is due to its design using ES Modules and esbuild. This means developers get feedback much faster. They experience shorter wait times and can make productive commits more often.
• Testing Efficiency: Built on top of Vite, Vitest inherits its speed. Benchmarks show that Vitest runs tests 10 to 20 times faster than Jest in “watch” mode, especially in modern TypeScript projects. This leads to quicker and easier Test Driven Development (TDD) cycles. As a result, software quality and maintainability improve.
• Compatibility and Developer Experience: If you use Vite, adding Vitest is easy. This choice avoids the compatibility problems that can happen when using Jest with Vite. This reduces technical friction and errors from complex or incompatible configurations.

Migration shouldn’t be a leap of faith, but a decision informed by concrete data and aligned with your business and team goals. Using a data-driven development mindset helps reduce risk and boost tech ROI. Most importantly, it leads to better products in less time.

Our Experience: A Step-by-Step Data-Driven Process

At Cabify, we aimed to test how migrating our Webpack and Jest stack to Vite and Vitest would affect one of our main internal apps: Remedios. Our support agents use this application every day. It helps them fix issues that users have during ride-hailing or logistics services. Remedios is vital for our operations. So, we had to ensure that changes to our development and testing tools would boost speed and enhance the developer experience. They also needed to boost efficiency and reliability for users who rely on the app in critical situations. We approached the migration as a data-driven process. First, we set clear metrics. Then, we documented every step. This way, we could assess how the transition affected our workflow and service quality.

Defining Key Metrics

Before writing a single line of code, we sat down to define what we wanted to measure and why. We established a set of metrics to test the real impact of the migration on our workflow.

The factors included are:

• Build times
• Hot reload speed
• Test execution times (unit, style, and acceptance)
• Final bundle size
• Dev server startup time
• CI pipeline duration

The goal was clear: align each metric with a real improvement in developer experience or product performance.

Measuring the Baseline

With our metrics defined, the next step was to measure the starting point using our original Webpack and Jest setup. This initial snapshot was key for comparing any improvements or regressions after migration. We collected these data points both in local environments and CI, ensuring the analysis was as complete and realistic as possible.

The Migration, Step by Step

We approached the migration as a controlled experiment. First, we migrated the build tool from Webpack to Vite, ensuring all critical processes continued to work properly. Then, we switched from Jest to Vitest for testing. Finally, we adjusted configurations and scripts to keep compatibility and test coverage.

Evaluation and Learnings

Once the migration was complete, we measured the same metrics we had recorded at the beginning. This comparison helped us see the real effects of the changes. We could then make smart choices about using the new tools fully.

The results were clear and, in most cases, very positive:

Performance Results Summary

Detailed Results

• Initial Build Time: Initial build time dropped by 55% locally and 37% in CI, notably speeding up environment startup and CI integration.
• Hot Reload Time: Hot reloading now happens almost instantly, making development much better.
• Unit Test Execution Time: In CI, unit test execution time decreased by 24%, while local execution time increased on the first run. But, thanks to Vitest’s efficient “watch” mode, the day-to-day impact was minimal, as later runs were much faster.
• Style Test Execution Time: Style tests in CI also benefited, with a 28% reduction in execution time.
• Acceptance Test Execution Time: Acceptance tests ran 23% faster, both locally and in CI. This speed boosts validation cycles, making them more agile and efficient.
• Bundle Size: The parsed bundle size dropped by 13%, though the compressed (GZIP) size increased slightly. This small increase had no noticeable impact on end-user performance.
• Server Start: The development server start-up time dropped 95%, going from nearly 13 seconds to under one second. This change greatly improved equipment agility.
• Pipeline Duration: The total CI pipeline duration dropped by 35–50%. This change enables more deployments and quicker feedback for the development team.

One of our biggest wins, besides the performance metrics, was simplifying the codebase. The migration helped us cut 5,329 lines of code from the repository. You mainly remove packages tied to Webpack, Jest, and Babel. These aren’t needed anymore because Vite uses esbuild. This tool is faster than Babel for transpiling and packaging. It also supports most modern JavaScript and TypeScript features. Also, with the tests’ migration to Vitest, we have taken the opportunity to refactor some of them by removing duplicate and inefficient code. This reduction means less complexity and a smaller maintenance surface. It also brings greater clarity and makes future project changes easier.

In summary, the migration greatly improved efficiency and developer experience. This shows the value of making technical choices based on data, not just gut feelings. Also, simplifying the codebase boosts the benefits of using modern, integrated tools in our tech stack.

Retrospective: One Phase or Two?

Looking back, another key takeaway from this process was reflecting on our migration strategy. If I had to approach this change again, I’d split the migration into two phases. First, I’d move from Webpack to Vite. This way, we can ensure the development and build flow work well with the new tool. Then, I’d handle the switch from Jest to Vitest. This phased approach helps isolate potential issues. It confirms each change on its own, making troubleshooting easier. This also lowers the risk of unexpected incidents.

It’s also important to know that using Jest with Vite may require extra setup. This combination doesn’t always integrate as smoothly as Vitest. The choice to migrate in one or two phases depends on the project context, team experience, and codebase complexity.