@quasar/app v2 RFC

[rstoenescu]

Below are the features and upgrades that are currently planned for "@quasar/app" v2. Target is to take 5 minute max to upgrade any project to it.

This list will keep getting updated.

• "@quasar/babel-preset-app" > core-js v3
• One source of truth for browser compatibility (package.json > browserslist array)
• Detect if IE11 support is needed based on package.json > browserslist array (removing quasar.conf > supportIE flag)
• New prop in quasar.conf.js > build > transpile (Boolean) -- enables Babel transpilation or not; transpile=false equals to q/app v1 "modern build" (--modern becomes obsolete, so removing)
• Babel transpiles features based on support inferred from package.json > browserslist; This removes the need for transpiling directly to ES5 (as in q/app v1)
• workbox v5
• capacitor v2
• capacitor plugins over HTTPS
• /src/statics -> /public (so root statics will be easy to add; example: robots.txt etc)
• copy-webpack-plugin v6
• auto stringify quasar.conf.js > build > env entries
• html-webpack-plugin v4
• icongenie support for new /public folder
• drop Quasar 0.x compatibility checks (also speeds up start time)
• SSR with custom public path
• Support for both regex and string format for build > transpileDependencies (+ perf under the covers, generating one regex out of all entries)
• Upgrade guide

[J3m5]

Great news! Will there be something planned about Vue 3 compatibility ?

[webnoob]

v2.0 in general will be implementing Vue 3.0, yes.

Sorry, misinformation on this one. QApp v2.0 won't be incorporating Vue 3. That'll be QApp v3.0 (As it stands at the moment).

[rstoenescu]

We are waiting for the final Vue 3 build and we will start working towards Quasar 2.0 which will be written using Vue 3.

[rstoenescu]

Current stage: internal testing

[rstoenescu]

Planned release: Thursday, 18 Jun Friday, 19 Jun.

[J3m5]

After thinking about it, we may have missed the point of the modern build or modern mode.

The point of having a modern mode, like with the Vue CLI, is to be able to distribute 2 versions of the application files.
One that is compatible with the browsers that support ES modules and the module attribute in script blocks and the older ones that doesn't support it.

And omitting this, is equivalent to just setting the browserlist with the version of the browsers that support it.

At then end, the purpose of modern mode, it to make your application compatible with the vast majority of browsers without impacting the new ones too much.

What do you think @rstoenescu ?

[rstoenescu]

@J3m5 The two versions trick may have had a lot more sense in the past than the present times. Nowadays, almost all browsers run with modern JS standards. It's exceptions like IE11 (~1% of global marketshare) which make our work harder. It just doesn't makes sense at the moment to invest in the double versions support (which is fading its usefulness with each day passing -- and would also double the build time) when there's other much more useful things on our plate, like the auto-routing or new UI components and directives.

[J3m5]

That's what I'm thinking too, just wanted to be sure.

[ibrainventures]

@rstoenescu
before i upgrade .. is this working with the nullish-coalescing and optional-chaining ?
last state was, that on the modern build it failed, and we are using those many times ..
btw. great job .. love it!

[rstoenescu]

@ibrainventures unfortunately, this is based entirely on webpack. And webpack 4 is using an old parser. However, the great new thing about q/app v2 is that now you can use Babel again and it will look at package.json > browserslist to determine what JS feature actually needs transpiling. Your code will no longer dumb down to ES5 automatically (unless you use a browserslist query that forces support for ES5-only browsers like IE11). Should you need additional babel plugins (for stage X features), you can supply them in babel.config.js -- the end result being Babel will transpile before Webpack handles the file. Should you want to maintain what we called "modern build" in q/app v1, it is sufficient to edit quasar.conf.js > build > transpile: false, but in this case we are yet again at the mercy of Webpack's parser.

[ibrainventures]

@rstoenescu
great .. thanks for the details .. (may also for others usefull), those two links for the dependecies ..

(rulesets)
https://github.com/browserslist/browserslist

(es-6 features)
https://caniuse.com/#feat=es6-module

[rstoenescu]

It's in the browsers support docs page which is linked from the release notes and also the upgrade guide.

[MaximSemenov]

@ibrainventures unfortunately, this is based entirely on webpack. And webpack 4 is using an old parser. However, the great new thing about q/app v2 is that now you can use Babel again and it will look at package.json > browserslist to determine what JS feature actually needs transpiling. Your code will no longer dumb down to ES5 automatically (unless you use a browserslist query that forces support for ES5-only browsers like IE11). Should you need additional babel plugins (for stage X features), you can supply them in babel.config.js -- the end result being Babel will transpile before Webpack handles the file. Should you want to maintain what we called "modern build" in q/app v1, it is sufficient to edit quasar.conf.js > build > transpile: false, but in this case we are yet again at the mercy of Webpack's parser.

Thanks a lot for all your work @rstoenescu I love the framework so much. I really do not understand why Quasar 2.14.1 does not transpile to ES5 I force browserList to do so:

"browserslist": [ "IE 9", "last 2 version" ],

I still get let and const. I just need to try something to see to ES5 would perform. We have a lot of weird browsers lately and I migrated to Quasar but the old site on vanillaJS sells better than fancy Quasar V2 + Vue3, so It's really sad.