Quasar ships v2 components on a v3 build tool, and its docs are packaged for agents

Seven output targets from one codebase

The README's claim is a list of delivery modes: high-performance, accessible single page apps, SSR apps, SSG apps, PWAs, browser extensions, hybrid mobile apps and Electron apps, all from the same codebase.

That is the structural argument for the framework, and it is a different argument from having a component library. In most stacks the choice between a static site, a server-rendered app and a desktop app is a choice of scaffolding tool and a layer of build configuration.

The words that come with the list matter too. Accessible is stated as a property of what you build, not as an add-on, and the framework is described as enterprise-ready in the same heading. Those are claims to test against your own accessibility requirements rather than accept, and the components you actually use are where that test happens.

The components are v2 and the build tool is v3

The release list is the clearest evidence that this is a monorepo of separately versioned packages. The latest are `quasar-v2.35.2` on 2026-10-19, `@quasar/app-vite-v3.10.3` on 2026-10-15 and `quasar-v2.35.1` on 2026-10-12.

So the component library is on its second major version and the build tooling built on Vite is on its third, and neither number tells you anything about the other. A team that reads a tutorial written for a different combination of those two majors is reading code that may not match what a fresh install gives.

The versioning policy is stated plainly, Semantic Versioning 2.0, and the default branch is named `dev`, which is the branch a reader lands on when they open the repository. The repository is not archived and the last push was on 2026-10-19, so the branch is current and the releases are frequent, which makes pinning both package names the practical requirement rather than an optional precaution.

context7.json is what makes the docs agent-readable

The README's second promise is that the documentation and API can be read by an AI coding agent offline. That claim has a file behind it in the repository root, `context7.json`, next to an `mcp/` package, an `AGENTS.md`, a `CLAUDE.md` and a `.claude/` directory.

That is the useful part for an evaluator. A claim that documentation is agent-readable is otherwise unfalsifiable, but a context configuration file at the root is something you can open and read, and an MCP package is a separate published surface with its own version and its own test target in the monorepo's test script.

The consequence for a team is that the agent-facing documentation is a build artefact of the same project as the components, so it moves when the framework moves. Which also means it can be out of step with the version you installed, and the version question from the previous section applies here too: an agent reading the current docs is not necessarily reading the docs for the majors you have pinned.

Eight test workflows, one per workspace

The README links eight GitHub Actions workflows by name, and the names describe the monorepo's shape better than any directory listing: ui-tests, ui-types, app-vite-tests, cli-tests, create-quasar-tests, vite-plugin-tests, utils-tests and docs-tests.

The root package.json agrees. Its `test:all` script filters nine workspaces in turn, the component library first, then the utilities, the Vite plugin, the CLI, the MCP package, the icon generator, the documentation site, the app-vite package and the scaffolder. There are also dedicated `vue-ecosystem-ci` and `vite-ecosystem-ci` scripts that build and test against each ecosystem separately.

So the test surface is per package, not per project. A change to `ui/` is validated by one workflow and a change to `cli/` by another, which means a regression shows up as a failing package rather than as a broken application, and a contributor needs to know which workspace they touched. The `lint:ui:check` script exists separately for the same reason, scoping the formatter and the linter to `./ui` alone.

The lint step fails on a lockfile peer variant

The lint command is three things, and the third is the one that tells you this repository has outgrown a single-package setup:

oxfmt && oxlint --fix --no-error-on-unmatched-pattern && node check-lockfile-peer-variants.js

A formatter, a linter, and a custom script that checks the lockfile for peer dependency variants. In a monorepo with a pnpm lockfile, a peer range that resolves differently in one workspace than in another is a real class of bug, and the project has written a script for it rather than leaving it to review. The `lint:check` variant runs the same chain without fixing.

Around that sit three linters and a hook system. Formatting and linting are oxfmt and oxlint, configured by `.oxfmtrc.json` and `.oxlintrc.json`, with a `.sasslintrc` for stylesheets, and husky is installed by the `prepare` script. `lint-staged` runs on commits and covers `js`, `ts`, `vue`, `mjs`, `cjs`, `json`, `css`, `sass` and `md`, invoking the linter with warnings denied. The package manager is pinned in the manifest at `[email protected]`.

The scaffolder and the icon generator are their own packages

The top level of the repository is the package list. `ui/` holds the components, `app-vite/` the Vite-based build, `cli/` the command line, `create-quasar/` the project scaffolder, `vite-plugin/` the plugin, `utils/` the shared packages, `extras/` the add-ons, `icongenie/` the icon generator, `mcp/` the agent-facing server, and `docs/` the documentation site.

Read as a workflow, that is the order in which a user meets the project: create a project, run it, build it, then use the pieces of it. It is also the order in which a team inherits upgrade decisions, because each directory is published separately and can move on its own schedule, which is exactly what the v2 components and v3 app-vite releases demonstrate.

The governance files sit alongside them. There is a ROADMAP.md, a SECURITY.md, a CONTRIBUTING.md, a CODEOWNERS-adjacent `.coderabbit.yaml` for automated review, and both AGENTS.md and CLAUDE.md at the root, which is the same agent-facing pattern the README describes in its own words.

Sponsors, a curated list, and an explicit request to your employer

The funding story is in the README, in more detail than most projects give it. Quasar is described as an MIT-licensed open source project whose ongoing development is made possible by sponsors and backers, followed by a table of sponsoring companies, and then a sentence that is unusual in a README: if you use Quasar at work, drop a message to your management about sponsoring them, with a donation page and a page explaining why donations matter.

That sentence is the most informative line in the file about who pays for a framework, and it tells you what a commercial adoption looks like from the maintainers' side.

The community surface is the usual four: the documentation at quasar.dev, chat on the community Discord at chat.quasar.dev, questions on the community forum at forum.quasar.dev, and release announcements on the project's Twitter account. The licence is MIT, with the copyright line reading 2015-present Razvan Stoenescu, which is also a reasonable answer to how old the project is. Contributors are asked to add their own projects to a separate curated list repository, quasar-awesome, by pull request.

Editorial conclusion

Quasar fits a Vue team that expects to change deployment target rather than rewrite an application, and that wants the component library, the build tool and the scaffolder from one monorepo. It does not fit a team that wants a single dependency to track, since the component library and the app-vite tooling carry separate major versions, and it does not fit a non-Vue project. Before adopting, check the version of both `quasar` and `@quasar/app-vite` rather than assuming they move together, and read the default branch's `dev` name into your upgrade planning.

Frequently asked questions

Official sources

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