Vuetify: two major versions shipping, and a Node floor of 24.11.1

The release list interleaves two majors, one day apart

Look at the three most recent releases. v4.2.2 shipped on 2026-09-23, v3.13.5 shipped on 2026-09-22, and v4.2.1 shipped on 2026-09-09. Two major lines are being cut at the same time, and the patch releases of the older line are landing in the same window as the minor work on the new one. That single fact reframes every other version question about the project. It means the major you get is determined by the tag you install, not by the state of the codebase, and it means the long-term support promise, stated as a minimum of 6 months for major releases, is a promise you can only evaluate against the line you have chosen. The ecosystem table adds to the ambiguity rather than resolving it, since the Playground entry describes itself in terms of Vuetify 3. Before anything else, decide v3 or v4 and write it down, because a project that drifts between them inherits two sets of component APIs.

Three of the four scaffold commands can hand you an older template

There are four ways to start a project, one per package manager, and they are not equivalent.

pnpm create vuetify

yarn create vuetify

npm create vuetify@latest

bun create vuetify

Only the npm form carries an explicit `@latest`, which pins the scaffolder itself to the newest published version. The pnpm, yarn, and bun forms resolve whatever the `create` package resolves to for that tool at that moment. With two major lines releasing, that difference is not cosmetic: a scaffold is a template that already contains code written against one major, and a scaffolder that has not been updated will produce a v3 project even though v4 is what you would get from npm. The practical consequence is that the manager you happen to prefer can quietly decide your major version. After scaffolding, check what the generated project actually depends on rather than assuming the newest line.

The repository's only container serves the docs, not the library

There is a `Dockerfile` and a `docker-compose.yml` at the root of what is a component library, and neither of them packages the components. The compose file defines a single service named `docs`, built from `caddy:alpine`, publishing `${PORT:-8095}` to port 80, and mounting `./packages/docs/dist` into the server with a `Caddyfile` from the docs build. The `Dockerfile` does the same thing with a pinned base, `FROM caddy:2.10.2-alpine`, copying the built docs and that Caddyfile into `/srv`. So if you were looking for a container image to drop the framework into, there is none in this repository, and what exists is a local way to preview the documentation site. Note also that the two files disagree about how tightly the base image is pinned, with the Dockerfile naming an exact Caddy version and the compose file using the floating `caddy:alpine` tag, so the compose path is the one that can drift under you.

The prepare script downloads a browser, and the semicolons let it continue

The root manifest sets an engine floor of Node at `>=24.11.1`, and a `.nvmrc` sits beside it. That is the version you need before anything else runs. More interesting is what the workspace does on install.

    "prepare": "husky; node scripts/post-install.js; $CI || pnpm exec playwright install chromium",

Three commands, joined with semicolons. The first sets up husky hooks, the second runs a post-install script, and the third downloads Playwright's Chromium, guarded by `$CI ||` so the download is skipped only when a CI environment variable is set. Because the separator is a semicolon rather than a chained `&&`, a failure in an earlier command does not stop the later one from running, which means a partial failure can leave you with hooks or a browser installed but the project half-configured. For anyone cloning the repository rather than consuming the published package, the practical effect is that a first install moves a browser download across your network, and setting CI to dodge it changes what the local environment ends up with.

The license field is empty while the project calls itself MIT

The repository metadata reports no license assertion at all, while the README states that Vuetify is a MIT licensed project developed and maintained by the Core Team, and a `LICENSE.md` file is present at the root. The prose and the file agree with each other and disagree with the machine-readable field. That gap has a concrete effect on anyone running tooling rather than reading: a license scanner, a compliance check, or an internal policy gate that reads package metadata will see nothing and will flag the dependency until somebody opens the file. If you are clearing a dependency for an organization, resolve it from `LICENSE.md` and record that, rather than relying on the field. The sponsorship routes are spelled out in the same section, across GitHub Sponsors, Open Collective, Tidelift, and PayPal, and the page is explicit that GitHub Sponsors funds go directly to John Leider while Open Collective funds are held transparently and used to compensate Core team members and their expenses.

Customization has three layers, and no page says which one wins

There are three named customization mechanisms, each with its own documentation page, and they are not the same kind of thing. SASS and SCSS variables change how the stylesheets compile. The default configuration, documented under presets, is a runtime object. Blueprints are a third option again. The README links all three as customization options and stops there, which means the one question that bites teams in practice is left open: what happens when two of them disagree about the same thing. A theme decided in the Sass layer and a theme decided in the default configuration are both valid inputs, and nothing on this page establishes a precedence between them. Plan for that by picking one layer per property and treating the other two as fallbacks, rather than discovering the conflict when a component renders in a colour nobody chose.

The major upgrade is delegated to a plugin in another repository

The way out of a major version is not described in this repository. The ecosystem table nominates a tool for it: Vuetify ESLint is described as an opinionated ESLint config for styling plus an ESLint plugin for upgrading Vuetify version. So the answer to how you get from v3 to v4 is a plugin you install from a separate repository, and its output is lint findings rather than a codemod you run once. Two other pieces of the story are also external. Vuetify Loader is a monorepo of compiler plugins for autoloading Vuetify components and configuring styles, which is where the automatic tree-shaking and the no-import setup actually live, and Vuetify MCP is a Model Context Protocol server for developing with Vuetify and agents. The consequence for planning is that this repository is not self-contained for any of the three tasks that matter at a version boundary: upgrading, tree-shaking, and component autoloading all mean adopting and configuring code from elsewhere.

42+ languages means a translation pipeline, not 42 shipped translations

Internationalization is a headline feature, stated as 42+ supported languages, and there is a `crowdin.yml` at the root of the repository. That file is the whole explanation of how the number is produced. The languages are managed as a translation project in an external service, and the count describes the state of that project rather than the contents of any particular release. The distinction matters when you are pinning a version, because the number of locales in the translation platform and the number of translated strings inside the tag you installed are two different measurements, and nothing in the README ties them together. Treat the figure as an upper bound on coverage rather than a guarantee for your locale, and check the specific strings your interface depends on rather than trusting the headline.

Editorial conclusion

Adopt it when you want a full component set with responsive defaults, a documented theming layer, and long-term support stated at a minimum of six months per major, and when you are willing to stay on one major line deliberately. Do not start a new project without pinning which major you are on, because both are releasing and the scaffold commands do not all agree on which template you get. Before you build, confirm your Node version clears 24.11.1, read LICENSE.md rather than trusting the empty license field in package metadata, and plan the major upgrade around the separate ESLint plugin that the project nominates for it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. vuetifyjs/vuetify on GitHub