Quasar Framework: one Vue codebase for web, mobile, desktop and browser extensions

The problem Quasar solves: one Vue codebase, many build targets

Most Vue projects start as a web app and then accumulate a second toolchain when someone asks for a mobile build, and a third when someone asks for a desktop build. Quasar's answer is to make the target a build mode of the same project rather than a separate repository. The README lists the modes it covers: Single Page Apps, SSR Apps, SSG Apps, PWAs, browser extensions, hybrid mobile apps and Electron apps, all from the same codebase. The topics list on the repository confirms the same spread: android, ios, electron, pwa, server-side-rendering, browser-extension.

The audience is therefore a Vue team that already knows it will ship to more than one surface, or a team that wants a component library with Material Design conventions and tooling that scaffolds the whole thing. If you are building a single web app that will never leave the browser, the cross-platform machinery is weight you carry for nothing. The framework is MIT-licensed, and the README frames it as enterprise-ready with documentation that an AI coding agent can read offline, which is a positioning statement rather than a technical guarantee.

How the monorepo is split, and what each package does

The repository is a pnpm workspace, and the top-level directories map closely to the published packages. ui/ holds the component library published as quasar. app-vite/ is the application build tooling published as @quasar/app-vite, which is where the build modes are implemented. cli/ is @quasar/cli, the command line entry point. create-quasar/ is the scaffolding package. vite-plugin/ is @quasar/vite-plugin, which wires Quasar into a Vite build. extras/ is @quasar/extras, the icons and fonts. icongenie/ is @quasar/icongenie, for generating app icons and splash screens. utils/ holds shared utilities, and mcp/ is @quasar/mcp.

The root package.json is private and only orchestrates: it declares [email protected] as the package manager, runs tests through pnpm --filter quasar test, and defines a test:all script that fans out across utils, @quasar/vite-plugin, @quasar/cli, @quasar/mcp, quasar.dev, @quasar/app-vite and create-quasar. Linting is handled by oxfmt and oxlint plus a check-lockfile-peer-variants.js script. That script name is a useful signal: peer dependency variants across the workspace are treated as something that can drift and break, so it is checked.

One architectural detail worth noticing is that the CLI, the app tooling and the UI library are separate packages with separate release tags. The recent releases show quasar-v2.33.0, @quasar/app-vite-v3.9.0 and @quasar/mcp-v1.0.0 all published on the same day. Version numbers of the UI library and the app tooling do not move together, so an upgrade is two decisions, not one.

Installing Quasar and running a first build

The README does not document install steps beyond the package badges, which point at create-quasar, @quasar/cli and @quasar/app-vite on npm. The scaffolding package is the entry point, and the repository's own test scripts reference it directly:

pnpm --filter create-quasar test

That command appears in the root package.json test:all script, so it is the project's own way of exercising the scaffolding package. For a new project, the README's badge for create-quasar is the pointer to the initializer; the exact invocation is not spelled out in the README, so check the create-quasar directory for its documented usage before running it.

Once a project exists, the CLI is the second piece. The repository ships @quasar/cli as a package, and the root test:all script exercises it the same way:

pnpm --filter @quasar/cli test

Inside a generated project, the app tooling is what runs the development server and the production build. The root package.json exposes those through the workspace, and the app-vite package is the one that owns the build modes:

pnpm --filter @quasar/app-vite test

Expect the app tooling to be the layer that decides which target you are building. The README does not document rollback or a version pinning strategy for generated projects, so treat the generated package.json as the source of truth for which Quasar versions you are on.

Where the cross-platform promise gets expensive

A single codebase does not mean a single set of platform constraints. Hybrid mobile builds still need the native toolchains for Android and iOS installed and configured on the machine doing the build. Electron builds produce desktop binaries that need their own packaging and signing story. Browser extension builds have a manifest and a permission model that no amount of shared Vue code abstracts away. Quasar reduces the amount of application code you duplicate; it does not remove the per-platform build and release work.

The second cost is version coupling. Because quasar (the UI library) and @quasar/app-vite (the build tooling) release independently, an upgrade can move one without the other. The repository's own lint script explicitly checks lockfile peer variants, which suggests the maintainers consider peer dependency drift a realistic failure mode rather than a theoretical one. If you upgrade the UI library and skip the app tooling, you are running a combination the project may not test.

The third limitation is the one the README leaves unstated: it does not document an escape hatch for ejecting from the Quasar build pipeline. If @quasar/app-vite's build modes do not cover what you need, the documented path is to work within them, not around them. That is a reasonable design for a framework with opinions, but it is a real constraint for teams that need a custom build step the tooling does not anticipate.

Quasar compared with plain Vite plus Vue

The honest alternative is a plain Vite project with Vue and a component library of your choice. The difference is not quality, it is where the decisions live. With plain Vite, you choose the router, the state layer, the component library, the SSR solution and the mobile wrapper separately, and you own the integration between them. With Quasar, those choices are made for you and encoded in @quasar/app-vite build modes, with the UI library in ui/ providing the components.

That trade favors Quasar when the platform matrix is the hard part of your project. If you need a web app, a PWA and an Electron build that share routing and state, Quasar's build modes replace a pile of separate configuration. It favors plain Vite when the platform matrix is trivial and your team has strong opinions about the component layer, because Quasar's components come with Material Design conventions that you would be adopting wholesale.

There is also a middle path visible in the repository itself: @quasar/vite-plugin exists as a separate package, and the root package.json runs a vite-ecosystem-ci:test script that builds the UI library and then runs @quasar/vite-plugin tests. That suggests the UI library can be consumed through a Vite plugin rather than through the full app tooling, which is a smaller commitment than adopting the whole build system.

Maintenance, licences and what an upgrade actually costs

The repository is not archived, and the last push was on 2026-09-17, the same day as the quasar-v2.33.0, @quasar/app-vite-v3.9.0 and @quasar/mcp-v1.0.0 releases. That is a same-day release train across the packages, which is a stronger maintenance signal than a single tag would be. The default branch is dev, so the branch you see on GitHub is the integration branch, not a release branch.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive licence, and the practical implication is that you can ship closed-source applications built with Quasar. The README also points at a donation page and notes that development is supported by sponsors and backers. Sponsorship is not a licence condition, so it does not change your obligations, but it does mean the project's funding model is voluntary rather than commercial.

Upgrade cost is where the package split matters. Because the UI library and the app tooling version independently, an upgrade plan needs to name both. The root package.json's lint:check script runs check-lockfile-peer-variants.js, so a mismatched peer set is something the project itself tests for. Reproduce that check in your own project rather than assuming a single version bump covers everything.

Editorial conclusion

Adopt Quasar when you want one Vue codebase to cover web, PWA, hybrid mobile and Electron, and you accept that the build tooling and the platform matrix are part of the product. Do not adopt it if your team wants a plain Vite plus Vue setup with no framework opinions, or if you need a build mode the repository does not ship. Before committing, scaffold a project with create-quasar, pick the modes you actually need, and check that the generated package.json pins the Quasar packages you expect.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. quasarframework/quasar on GitHub
4. README
5. Releases