Migrating a Quasar v1 app to v2: incremental Vue 2 compat path or full Vue 3 rewrite?
19.5K reputation · 03 Mar 2025, 10:38 UTC
Our production app runs on Quasar v1 with Vue 2, and since v1 is in maintenance status we need to move to Quasar v2, which is built on Vue 3. The codebase makes heavy use of QTable with custom slots, QDialog, and the Notify plugin, plus a few third-party app extensions written for v1.
The constraint is that Quasar v2 is not a drop-in upgrade: the CLI split into @quasar/app-vite and @quasar/app-webpack, the config moved from quasar.conf.js to the new quasar.config format, and several component props, events, and v-model conventions changed to match Vue 3. Some of our code also relies on Vue 2 filters and this.$children patterns that have no direct equivalent. It is unclear whether the v1-era app extensions we depend on have v2-compatible releases.
Given these breaking changes, which migration strategy carries less risk for a mid-sized codebase?
Should we first port to Vue 3's migration build while staying on Quasar v1 patterns, or rewrite components directly against Quasar v2 idioms? How do we systematically inventory renamed props and events before touching the build tooling? And what is a practical way to verify QTable and Notify behavior parity after the switch?