Challenge 3: Why "Vite Uses Rollup for Production" Actually Matters — Possible Solution ==================================================================== WHY THIS IS EASY TO OVERLOOK ------------------------------ Vite is commonly described, and often experienced, as one single, fast tool — a developer runs `vite` for development and `vite build` for production, and both commands live under the same tool's own command-line interface. It would be easy to assume the SAME underlying mechanism (native ESM serving, esbuild pre-bundling) is just running in a different mode for each command. WHY IT'S GENUINELY IMPORTANT, NOT A MINOR DETAIL ------------------------------ Per this chapter's own explanation, that assumption is actually wrong: the production build genuinely switches to Rollup, "a real, independent bundler" with its own separate codebase, separate behavior, and separate configuration surface from esbuild. Development and production aren't two modes of one pipeline — they are two GENUINELY DIFFERENT pipelines, built from two different underlying tools, that happen to be packaged together under one convenient command-line interface. Knowing this changes what a developer should actually expect: dev-mode behavior isn't a reliable preview of production behavior in the way it would be if both used the exact same underlying bundler. THE SPECIFIC PRACTICAL RISK NAMED ------------------------------ Per this chapter's own warn-box, because dev (native ESM + esbuild pre-bundling) and production (Rollup) are genuinely different pipelines, something that behaves correctly during development is NOT automatically guaranteed to behave identically once actually built for production — a real, occasionally-surprising source of "works in dev, breaks in prod" bugs specific to Vite's own dual-pipeline design. The chapter's own concrete recommendation is to always verify behavior against a real production build (`vite build`) rather than trusting dev-server behavior as the final word. WHY THIS WORKS AS AN ANSWER ------------------------------ It explains why the two-tool reality is easy to miss (both commands share one CLI), states plainly why it matters (dev behavior isn't a reliable stand-in for production behavior when the underlying tools genuinely differ), and names the specific practical risk (works-in- dev-breaks-in-prod bugs) the chapter itself calls out as the real consequence.