Quasar v2 is out! Read our announcement.

Is v2 stable?

YES

The plan

Our main focus at the moment is shipping Quasar v2 with Vue v3. The plan is to not introduce any breaking changes, unless forced by the vue 3 / vue-router 4 architectures.

Affected Quasar packages: "quasar", "@quasar/app".

Rough schedule

• First beta: "quasar" v2.0.0-beta.1 & "@quasar/app" v3.0.0-beta.1 - Jan 2021
• Stable releases: "quasar" v2.0.0 & "@quasar/app" v3.0.0 - Q2 2021

The code

The branch currently holding Quasar v2 is called dev (was previously vue3-work).

Donations

If you want to speed up the development of Quasar please consider donating to the project. With proper funding, it allows more of the team to work on the project in a much more dedicated manner.

Donations - https://donate.quasar.dev

If you're in a company and using Quasar for commercial projects, explain to your management the importance of monthly donations (eg. $200+) for open source projects: you're the one using it every day and this makes you the best suited person to convince them. Be creative! :slight_smile:

Quasar is saving your company tens of thousands of development hours (quite literally), which in turn is a pretty high money savings. Consider giving back a part of those savings to refuel the project itself :wink:

Update: June 21st 2021

Quasar v2 stable (with Vue.js 3) has been released! Time to party! https://github.com/quasarframework/quasar/discussions/9734

Update: June 19th 2021

Next release is v2.0.0 stable. Branch vue3-work has been merged into dev. The Qv1 work will now be done exclusively on the new v1 branch.

Update: April 27th 2021

We have passed the final major milestone: Quasar CLI now ships with Webpack 5, which was badly needed to support Node 13+. Faster build speeds and lower memory usage. We're just a few small steps away from getting Quasar v2 out of beta!

Update: April 4th 2021

The last Quasar CLI mode left to be enabled, which is SSR, is now also available. Here is the link to the upgrade guide on SSR. We are targeting for a 2 weeks testing period for SSR mode then we will release the official stable version of Quasar v2.

Update: February 16th 2021

We're close to the stable release. The only thing remaining is the SSR support. Quasar is SSR ready, however we're only going to enable SSR support as soon as these Vue3 SSR bugs (critical for us and your experience) are solved:

• ~https://github.com/vuejs/vue-next/issues/3244~ redirected to https://github.com/vuejs/vue-next/issues/2863
• https://github.com/vuejs/vue-next/issues/2386
• https://github.com/vuejs/vue-next/issues/3245
• https://github.com/vuejs/vue-next/issues/3243
• https://github.com/vuejs/vue-next/issues/3255

Update: February 10th 2021

SSR mode is ready (UI and CLI-wise) to be released. Unfortunately, there are quite a few Vue SSR bugs that need to be fixed before we enable the build mode for Quasar v2. We are in the process of reporting them and we'll start collaborating with the Vue team to help fix them.

Update: January 11th 2021

Hi All,

There are still some things being worked on for Quasar v2, but mainly we're now writing the migration guide. Our target for release of the public beta is within January 2021. The new version is based on Composition API. But it's not just a port to Vue 3. There are lots of significant performance enhancements in Quasar's algorithms too! You'll love it!

Unfortunately, the first beta release won't include SSR support, due to missing some upstream features in Vue 3, which we'll contribute to via PRs. We'll release SSR support during the beta stage lifecycle though.

We're also trying to integrate Webpack 5 support into the @quasar/app v3 release, but if we are unable to get this done (ie: external dependencies and such) then we'll shoot for @quasar/app v4 release.

Stable release will be anywhere within Q1 2021, but as is the case with OSS, it will be ready, when it's ready. And of course, it will be ready when we know the quality is high enough to meet both your expectations and ours.

In the meantime, the wonderful framework you've come to love is still here and you don't have to wait for Quasar v2 to start a new project with Vue 3's major new feature (i.e. using the composition API). Of course, if you choose to hold off on Vue 3 features, we'll make the upgrade as easy as possible for you. That's a promise. :slight_smile:

The Quasar Team

Is your feature request related to a problem? Please describe.

This proposal aims to resolve conflicts between Quasar and TailwindCSS with minimum changes. Currently, Quasar and TailwindCSS offer both useful classes. This post is not to discuss the pros and cons (you can debate here) but to ease the use of TailwindCSS with Quasar for those who want to.

After investigation (with the help of CSS compare and CSS sort), we can divide Quasar class names in 4 categories:

• Classes prefixed with q- : not a problem.
• Classes not prefixed but not redundant with TailwindCSS (some of these classes are utility classes and could be renamed to match TailwindCSS) : not a problem.
• Classes with the same name and behavior in both frameworks : not a problem.
• Classes with the same name but with a different behavior : it is a problem.

Hopefully, the last category contain only 12 classes in 5 files with few differences:

/* Quasar: flex.styl */
.flex{ display: flex; flex-wrap: wrap }
.order-first { order: -10000 }
.order-last { order: 10000 }
/* TailwindCSS */
.flex { display: flex }
.order-first { order: -9999 }
.order-last { order: 9999 }

/* Quasar: mouse.styl */
.cursor-not-allowed { cursor: not-allowed !important }
.cursor-pointer { cursor: pointer !important }
/* TailwindCSS */
.cursor-not-allowed { cursor: not-allowed }
.cursor-pointer { cursor: pointer }

/* Quasar: size.styl */
.block { display: block !important }
.inline-block { display: inline-block !important }
/* TailwindCSS */
.block { display: block }
.inline-block { display: inline-block }

/* Quasar: typography.styl */
.text-justify { text-align: justify; hyphens: auto }
/* TailwindCSS */
.text-justify { text-align: justify }

/* Quasar: visibility.styl */
.hidden { display: none !important }
.invisible { visibility: hidden !important }
.overflow-auto { overflow: auto !important }
.overflow-hidden { overflow: hidden !important }
/* TailwindCSS */
.hidden { display: none }
.invisible { visibility: hidden }
.overflow-auto { overflow: auto }
.overflow-hidden { overflow: hidden }

You can see that:

• for 8 classes, it is just a difference with the presence of !important in Quasar
• for 2 classes (order-first, order-last), the value chosen for the indexes differ from 1
• for 2 classes (flex, text-justify), a second property is added to the utility class in Quasar

I forgot to mention the particular case of colors that have the same problem of !important (the way I deal with them is described below).

Describe the solution you'd like

As a preferred solution and personal taste, it is possible with minimal modifications to change these 12 classes to avoid conflicts. For that, we could:

• check the pertinence of !important for the 8 classes (after a search they are not used in many components), remove it when unecessary or replace it with another class (named hiddenImportant instead of hidden for instance) or style in that particular cases.
• simply change the values of indexes for consistency (9999 or 10000 is arbitrary and will not impact anything).
• divide the two other classes to utility classes (by the way, for flex, we already have wrap to indicate flex-wrap: wrap) which will be more consistent.

For colors, a clean solution would be (in the case of !important being not that 'important' but a matter of taste) to offer a property in config to add/remove colors (kind of what it is done with brand).

I would also vote for renaming utility classes that only differ from names to have something really robust but it is not mandatory.

Describe alternatives you've considered

For now, for the 12 classes :

• I have chosen to use Quasar as the source of truth because classes are used in some components and I did not want to monkeypatch and maintain each of them on my own (considering that they could be updated by the Quasar team at anytime). Consequently, I use them with caution and add a comment for warning.

For now, I manage colors in this way :

• I recreate quasar.*.css files with a postinstall script that mimic what Quasar do to build CSS but with an index.styl without colors.styl. It is less a problem because it consists only in one file and I am not sure that the !important is relevant for the colors (I didn't encounter problems yet).
• I define all the colors in my tailwind.config.js and it is ok with Quasar that offers the same class names for customization.

Additional information

Also, I would like t o mention two other important concepts:

• Breakpoints : I have configured TailwindCSS to use the same values as Quasar in config. I know that these values can be changed in Quasar as they are stylus (or sass) variables but as I have seen mentions of them in components, I don't really know if it would impact these components badly if I change for instance md or lg values.
• PurgeCSS : I have managed to reduce Quasar core CSS and purge all CSS with something similar as this pull request. But instead of including all src components, I use the same technique that Quasar uses with its auto import process to keep only the styles of the components that I use.

Not a bug/issue/feature request, but a discussion area.

If you would like a Quasar meetup please list your top 3 areas?

For instance, mine would be:

1. Calgary (Canada)
2. Vancouver (Canada)
3. Toronto (Canada)

I am not saying this will happen in your location, but maybe we can get some community driven ones based on the highest concentration.

I think Quasar is almost perfect and I think adding the ability to generate a static website like Nuxt is better than maintaining a "Quasar + Nuxt starter kit" because I think Quasar gave us a freedom better than Nuxt and capabilities much better than Nuxt.

I don't expect this feature to be available in the next release I just want to see it someday available in the most perfect framework Quasar!

Dear Team,

that is my major issue on the QDialog. If you open a standard Dialog and there is a Input Field the virtual Keyboard overflow the entry-fields.

So no entry is possible .. Scrolling to the fields else is also prevented.

With the seamless Option, the entries are possible, but the scroll / overall handling of that seamless Dialog is awkward (Background-Scrolling etc.)

For Testing there is a Sandbox:

https://vtft7.sse.codesandbox.io/ e: https://codesandbox.io/s/codesandbox-app-vtft7

If you make a slow motion .. you will see, that standard Dialog scrolls short up - but it snaps down ..

That it is possible, to have a working Dialog with Input on ios Devices, you see on my codepen:

https://codepen.io/ibrainventures/full/eYYBdRE e: https://codepen.io/ibrainventures/pen/eYYBdRE

(here the Dialog is NOT snapping down - opened in an non seamless Dialog)

May the reason that it is working there (same Dialog Code) is, that the codepen wrapper is blocking some dyamic body-attaches by the quasar fw .. (i think so) (there are some .js routines).

So the solution is maybe to make that to the body element dynamic applied styles / classes (more) ios compatible - so that the explained snap-down will not occur...

This issue is really a big problem for me, because all kind of Dialogs (Login, Signup, Edit, etc.) are not usable for any iphone / ipad User.

Affected: All Apple i-devices with safari, IOS: 11, 12, 13, IpadOS: 13

It would be really great to get here a solution. Many thanks to the Team.

What happened?

As a developer that uses quasar using the Vite plugin When building a project that contains a quasar input component And previewing the build using npm run preview Then Vue throws an error Cannot read properties of undefined (reading 'accessCache')

You can find a codesandbox with the final build assets here: https://codesandbox.io/s/frosty-thunder-gxs0pt?file=/index.html

What did you expect to happen?

No error to happen in the final build

Reproduction URL

https://github.com/waldi/quasar-access-cache-bug

How to reproduce?

You can use the reproduction repo or create a new project from scratch:

1. Create a new Vite project (Basically following all steps here: https://quasar.dev/start/vite-plugin)

npm init vite@latest quasar-access-cache-bug -- --template vue
cd quasar-access-cache-bug
npm install quasar @quasar/extras
npm install -D @quasar/vite-plugin [email protected]

2. Change files:

// main.js

import { createApp } from "vue";
import { Quasar } from "quasar";
import "@quasar/extras/material-icons/material-icons.css";
import "quasar/dist/quasar.css";

import App from "./App.vue";

const myApp = createApp(App);

myApp.use(Quasar, {
  plugins: {}, // import Quasar plugins and add here
});

myApp.mount("#app");

// vite.config.js

import { defineConfig } from "vite";
import vue from "@vitejs/plugin-vue";
import { quasar, transformAssetUrls } from "@quasar/vite-plugin";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue({
      template: { transformAssetUrls },
    }),
    quasar(),
  ],
});

3. Use q-input component:

// App.vue

<script setup>
import { ref } from "vue";
const text = ref("");
</script>

<template>
  <q-input v-model="text"> </q-input>
</template>

<style></style>

4. Run npm run build && npm run preview
5. Open app in browser
6. Inspect developer console

Flavour

Quasar CLI with Vite (@quasar/cli | @quasar/app-vite)

Areas

Quasar CLI Commands/Configuration (@quasar/cli | @quasar/app-webpack | @quasar/app-vite), Components (quasar), SPA Mode

Platforms/Browsers

No response

Quasar info output

No response

Relevant log output

index.103dbd67.js:1 
TypeError: Cannot read properties of undefined (reading 'accessCache')
    at Object.defineProperty (index.103dbd67.js:1:45265)
    at Function.defineProperty (<anonymous>)
    at $n (index.103dbd67.js:1:55812)
    at cc (index.103dbd67.js:1:94717)
    at vc (index.103dbd67.js:1:96942)
    at setup (index.103dbd67.js:1:114952)
    at tt (index.103dbd67.js:1:12393)
    at pa (index.103dbd67.js:1:46698)
    at ma (index.103dbd67.js:1:46483)
    at I (index.103dbd67.js:1:34874)

Additional context

This bug seems to be related to the Vue version. If you fix the vue version in the package.json to: "vue": "3.2.25" then everything works fine.

Hi,

Since the app is in production, I see a lot of ResizeObserver loop limit exceeded errors in Sentry breaking my plan capacity. But I can't reproduce it.

I'm not using the QResizeObservable component.

Here I see the discussion saying we can ignore it: https://stackoverflow.com/questions/49384120/resizeobserver-loop-limit-exceeded

Is there a dependency doing that? Can we catch this error in order to don't log it?

Thanks for your work :100:

Software version

Operating System Centos NodeJs 9.8.0

Global packages
NPM 5.6.0 yarn 1.5.1 quasar-cli 0.15.14 vue-cli 2.9.3 cordova Not available

Important local packages
quasar-cli 0.15.14 quasar-framework 0.15.10 quasar-extras 1.0.2
vue 2.5.16
vue-router 3.0.1 vuex 3.0.1
electron Not available babel-core 6.26.0 webpack 3.11.0 webpack-dev-server 2.11.1

What did you get as the error?

ResizeObserver loop limit exceeded

What were you expecting?

No errors.

What steps did you take, to get the error?

I've seen the error in the errors log.

Hi all,

I'm working on a new logo for Quasar Framework, as my personal contribution to the project.

It's fully vector and square-bounded. If you like it, I could provide you the .svg file.

Comments and suggestions are welcome!

When I use the q-input component to input Chinese in the mac Safari browser, there will be repeated Chinese pinyin https://user-images.githubusercontent.com/28332458/117227421-58c3ba80-ae49-11eb-9f7a-b16cde53c1c0.mov

This is the correct effect on the Chrome browser https://user-images.githubusercontent.com/28332458/117227637-dc7da700-ae49-11eb-9251-0118697799c7.mov

Software version

Operating System - Darwin(18.6.0) - darwin/x64 NodeJs - 8.11.3

Global packages NPM - 6.7.0 yarn - Not installed @quasar/cli - 1.0.0-rc.2 cordova - 9.0.0 ([email protected])

Important local packages quasar - 1.0.0-rc.4 @quasar/app - 1.0.0-rc.6 @quasar/extras - 1.1.2

What did you get as the error?

No error information. Strictly UX related.

What were you expecting?

QInput elements on an iOS build seem to require two distinct taps to pull up the keyboard. The first tap gives it focus. The second tap then allows editing the text.

Expecting a single tap to both bring focus to the input and pull up the keyboard.

What steps did you take, to get the error?

Any QInput used in a native iOS build. Mobile web is not an issue. Android is not an issue.

Also: not an issue with our 0.17 iOS build.

Describe the bug When I upgraded quasar to the latest version (v1.3.0 to v1.5.7), all q-btn in my quasar project were on the mobile side, and the mac display was particularly long, normally displayed in the linux/windows chrome browser. Then I upgraded the project step by step from v1.3.0, when the upgrade to v1.5.0 occurred with the problem Codepen/jsFiddle/Codesandbox (required) Fork a Codepen (https://codepen.quasar.dev) or a jsFiddle (https://jsfiddle.quasar.dev) or a Codesandbox (https://codesandbox.quasar.dev) and hit save then copy-paste link here.

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior A clear and concise description of what you expected to happen.

Screenshots If applicable, add screenshots to help explain your problem.

Platform (please complete the following information): Operating System - Linux(4.19.0-6-amd64) - linux/x64 NodeJs - 10.17.0

Global packages NPM - 6.13.2 yarn - 1.19.2 @quasar/cli - 1.0.2 cordova - Not installed

Important local packages quasar - 1.5.0 -- Build high-performance VueJS user interfaces (SPA, PWA, SSR, Mobile and Desktop) in record time @quasar/app - 1.2.3 -- Quasar Framework local CLI @quasar/extras - 1.3.2 -- Quasar Framework fonts, icons and animations vue - 2.6.10 -- Reactive, component-oriented view layer for modern web interfaces. vue-router - 3.1.3 -- Official router for Vue.js 2 vuex - 3.1.1 -- state management for Vue.js

Additional context Add any other context about the problem here.

What happened?

i'm using quasar in my vitepress project,and I added a loading animation when the route changes, but I found that when the route is switched, the new page will scroll to the previous page position, which seems to be a bug, this is my code:

1. .vitepress/config.js

export default {
    Layout,
    NotFound: Error404,
    enhanceApp({app, router, siteData}) {
        initQuasar(app)

        router.onBeforeRouteChange = () => {
            Loading.show({message: '(ง •̀_•́)ง (*•̀ㅂ•́)و 努力加载中...'})
        }

        router.onAfterRouteChanged = () => {
            Loading.hide()
        }
    }
}

2. Layout.vue

<template>
  <q-img src="mountain.jpg" height="400px" alt="background">
    <h3 class="absolute-full flex flex-center">
      When in doubt, use brute force.
    </h3>
  </q-img>
  <div class="row animate__animated animate__fadeIn">
    <div class="col-10 offset-1 col-sm-8 offset-sm-2">
      <q-timeline :layout="layout" color="secondary">
        <q-timeline-entry heading>时间轴（{{summaries.length}}）</q-timeline-entry>
        <q-timeline-entry
            v-for="summary in summaries"
            :title="summary.title"
            :subtitle="summary.time"
            side="left"
        >
          <div class="text-caption">{{ summary.excerpt }}</div>
          <q-btn
              flat
              color="info"
              @click="router.go(summary.link)"
          >
            阅读全文
          </q-btn>
        </q-timeline-entry>
      </q-timeline>
    </div>
  </div>
</template>

<script setup>
import {computed} from 'vue'
import {useRouter} from 'vitepress'
import {useQuasar} from 'quasar'
import summaries from '../../../post/summary.json'

const router = useRouter()
const $q = useQuasar()

const layout = computed(() => $q.screen.lt.sm ? 'dense' : 'comfortable')
</script>

What did you expect to happen?

I expect the new page position is zero

Reproduction URL

https://codesandbox.io/p/github/YangQuan666/yangquan666.github.io/draft/elastic-darkness?file=%2Fdocs%2F.vitepress%2Ftheme%2Findex.js&selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A154%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A154%7D%5D&workspace=%257B%2522activeFileId%2522%253A%2522clcd9z83v000k7ni0e5h50brk%2522%252C%2522openFiles%2522%253A%255B%2522%252Fdocs%252Fpost%252Ftest.md%2522%252C%2522%252Fdocs%252F.vitepress%252Ftheme%252Fcomponents%252FTimeline.vue%2522%252C%2522%252Fdocs%252F.vitepress%252Ftheme%252Fstyle%252Fcustom.css%2522%255D%252C%2522sidebarPanel%2522%253A%2522EXPLORER%2522%252C%2522gitSidebarPanel%2522%253A%2522COMMIT%2522%252C%2522spaces%2522%253A%257B%2522clcda1wd300133b6gl4e5icbt%2522%253A%257B%2522key%2522%253A%2522clcda1wd300133b6gl4e5icbt%2522%252C%2522name%2522%253A%2522Default%2522%252C%2522devtools%2522%253A%255B%257B%2522type%2522%253A%2522PREVIEW%2522%252C%2522taskId%2522%253A%2522docs%253Adev%2522%252C%2522port%2522%253A5173%252C%2522key%2522%253A%2522clcdaaj3704ei3b6gh0g9ws2q%2522%252C%2522isMinimized%2522%253Afalse%252C%2522path%2522%253A%2522%252F%2522%257D%255D%257D%257D%252C%2522currentSpace%2522%253A%2522clcda1wd300133b6gl4e5icbt%2522%252C%2522spacesOrder%2522%253A%255B%2522clcda1wd300133b6gl4e5icbt%2522%255D%257D

How to reproduce?

1. open codesandbox
2. scroll down the page
3. Just click a button 阅读全文
4. new page while scroll to prev page position

Flavour

UMD

Areas

Plugins (quasar)

Platforms/Browsers

Chrome, Safari

Quasar info output

No response

Relevant log output

No response

Additional context

https://user-images.githubusercontent.com/27985301/210169370-ddc15ba2-04a9-48e3-866a-e6e6df474130.mov

What happened?

When there are many tooltip components, destroying the component can compromise performance. I ran some profiles and found that the problem is with the clearTimeout calls in the use-anchor and use-timeout.

In my case, when switching pages in my application, it was taking 500ms-1000ms just to destroy the components (after the workaround below, the time was reduced to 40ms-80ms).

I did a performance test comparing the clearTimeout call with undefined and only calling it when the ID exists.

For now, I have replaced the default clearInterval and clearTimeout methods.

    const originalClearInterval = clearInterval;
    const originalClearTimeout = clearTimeout;

    clearInterval = id => {
        if (id) originalClearInterval(id);
    };
    clearTimeout = id => {
        if (id) originalClearTimeout(id);
    };

What did you expect to happen?

Before executing clearTimeout and clearInterval in all calls, should check if the ID is defined, for example as follows:

// use-anchor.js
  onBeforeUnmount(() => {
    clearTimeout(touchTimer)
    unconfigureAnchorEl()
  })

to:

// use-anchor.js
  onBeforeUnmount(() => {
    if (touchTimer) {
        clearTimeout(touchTimer)
    }
    unconfigureAnchorEl()
  })

Reproduction URL

https://jsbench.me/i4lcbtfdx4/1

How to reproduce?

Create a many components with tooltip and destroy then

Flavour

Quasar CLI with Webpack (@quasar/cli | @quasar/app-webpack)

Areas

Composables (quasar)

Platforms/Browsers

Chrome

Quasar info output

Operating System - Windows_NT(10.0.22000) - win32/x64
NodeJs - 16.14.2

Global packages
  NPM - 8.9.0
  yarn - 1.22.15
  @quasar/cli - 1.3.2
  @quasar/icongenie - Not installed
  cordova - Not installed

Important local packages
  quasar - 2.11.3 -- Build high-performance VueJS user interfaces (SPA, PWA, SSR, Mobile and Desktop) in record time
  @quasar/app-webpack - 3.6.2 -- Quasar Framework App CLI with Webpack
  @quasar/extras - 1.15.9 -- Quasar Framework fonts, icons and animations
  eslint-plugin-quasar - Not installed
  vue - 3.2.41 -- The progressive JavaScript framework for building modern web UI.
  vue-router - 4.1.6
  pinia - Not installed
  vuex - 4.1.0 -- state management for Vue.js
  electron - Not installed
  electron-packager - Not installed
  electron-builder - Not installed
  @babel/core - 7.19.6 -- Babel compiler core.
  webpack - 5.74.0 -- Packs CommonJs/AMD modules for the browser. Allows to split your codebase into multiple bundles, which can be loaded on demand. Support loaders to preprocess files, i.e. json, jsx, es7, css, less, ... and your custom stuff.
  webpack-dev-server - 4.9.3 -- Serves a webpack app. Updates the browser on changes.
  workbox-webpack-plugin - Not installed
  register-service-worker - 1.7.2 -- Script for registering service worker, with hooks
  typescript - 4.5.5 -- TypeScript is a language for application scale JavaScript development
  @capacitor/core - Not installed
  @capacitor/cli - Not installed
  @capacitor/android - Not installed
  @capacitor/ios - Not installed

Quasar App Extensions
  @quasar/quasar-app-extension-qmarkdown - 2.0.0-beta.7 -- Display inline markdown in your Quasar App

Networking
  Host - DESKTOP-ENGH6PL
  Wi-Fi - 192.168.2.100
  vEthernet (WSL) - 172.18.192.1

Relevant log output

No response

Additional context

No response

What kind of change does this PR introduce?

• [ ] Bugfix
• [x] Feature
• [ ] Documentation
• [ ] Code style update
• [ ] Refactor
• [ ] Build-related changes
• [ ] Other, please describe:

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

The PR fulfills these requirements:

• [x] It's submitted to the dev branch (or v[X] branch)
• [x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• [ ] It's been tested on a Cordova (iOS, Android) app
• [ ] It's been tested on an Electron app
• [ ] Any necessary documentation has been added or updated in the docs or explained in the PR's description.

If adding a new feature, the PR's description includes:

• [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to start a new feature discussion first and wait for approval before working on it)

Other information: This commit has an effect to quasar upgrade command. We can use pnpm as quasar's dependence manageer now,but when we use quasar upgrade, it can not use pnpm to upgrade. Using yarn upgrade a pnpm installed project will make a mistake,so this feature is important! can fix #15055

Description

When upgrading Capacitor as described in the documentation (see the link below), you should also delete the www folder, otherwise the bundle files will be created twice (or even more), which will make the final APK file unnecessarily large. The more often you perform the upgrade steps, the more duplicates will result. So I would suggest to add the www folder to the folders to delete in the first step of the Upgrade guide in the documentation. I don't know if this only occurs with Vite because I did not test it with Webpack.

Thanks for all your work for such a great framework! I wish you a happy new year!

Documentation Section URL

https://quasar.dev/quasar-cli-vite/developing-capacitor-apps/capacitor-version-support#upgrading-capacitor

Flavour

Quasar CLI with Vite (@quasar/cli | @quasar/app-vite)

Areas

Capacitor Mode

What kind of change does this PR introduce?

• [ ] Bugfix
• [ ] Feature
• [x] Documentation
• [ ] Code style update
• [ ] Refactor
• [ ] Build-related changes
• [ ] Other, please describe:

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

The PR fulfills these requirements:

• [x] It's submitted to the dev branch (or v[X] branch)
• [x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• [ ] It's been tested on a Cordova (iOS, Android) app
• [ ] It's been tested on an Electron app
• [x] Any necessary documentation has been added or updated in the docs or explained in the PR's description.

If adding a new feature, the PR's description includes:

• [ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to start a new feature discussion first and wait for approval before working on it)

Other information: