Setting up webpack, Babel, linting, and hot module replacement by hand for every new Vue project was eating a half day we did not need to spend. Vue CLI's webpack template gives us a sensible, working configuration out of the box, and we now start every new client-facing Vue project from it rather than a hand-rolled setup.
What used to go wrong with hand-rolled setups
Before adopting Vue CLI, every new project's initial webpack config was copy-pasted and lightly adapted from whichever previous project's config the developer starting it happened to have handy, which meant small inconsistencies accumulated across projects over time — one project's Sass loader configured slightly differently than another's, one project missing a source map setting that made production debugging harder than it needed to be. None of these were individually serious, but collectively they meant every project had its own personality in ways that had nothing to do with the actual client work and everything to do with which config template it happened to descend from.
What Vue CLI's webpack template gives us out of the box
- Hot module replacement configured correctly from the start, rather than the fiddly manual setup we used to need to get component state preserved across a reload during development
- A sensible split between development and production webpack configs, with production automatically getting minification, tree-shaking, and cache-busting file hashes without any manual setup
- ESLint wired in with a sensible default rule set, catching a meaningful number of small mistakes — unused variables, missing keys in `v-for` loops — before they ever reach code review
- A working unit test setup using Karma and Mocha out of the box, for projects that want it, removing what used to be its own separate half-day of configuration work on top of the webpack setup itself
Where it is opinionated in ways we mostly agree with
It is opinionated in ways that mostly match what we would have configured ourselves anyway — the directory structure conventions, the build output naming scheme, the choice of Babel presets for browser compatibility targets. Where it does not match our preferences, ejecting or overriding specific pieces of the webpack config is straightforward, since the generated config remains readable and modifiable rather than hidden behind an abstraction that resists customization.
The one adjustment every project still needs
The template's defaults assume a fairly standard setup, and the one thing we consistently customize afterward is the API proxy configuration for local development, pointing the dev server at whichever backend a given client project uses so requests to `/api` during local development transparently forward to the real backend rather than hitting a 404 against the dev server itself. We have started keeping this specific piece of configuration in our own project template that wraps the CLI's default output, so it is one less thing every new project needs to rediscover from scratch.
The time saved, made concrete
The time saved on setup alone has been worth adopting it as a team standard — what used to be a half day of webpack configuration, plus the inevitable troubleshooting when something in that hand-rolled config behaved unexpectedly a few weeks into the project, is now a few minutes running the CLI's interactive prompts followed by our own small proxy configuration step. Multiplied across the dozen or so Vue projects we start in a typical year, that adds up to real calendar time that goes toward actual client work instead of reassembling the same build tooling from memory each time.