Webpack 5 support

[IlCallo]

https://webpack.js.org/blog/2020-10-10-webpack-5-release/ https://webpack.js.org/migrate/5/

webpack 5 is out and it's time we go way down into that rabbit hole :D

We'll use this issue to keep track of everything. We plan to ship Quasar 2 with Webpack 5 support, or add it right after with a @quasar/app update, ~but could push back the upgrade to Quasar 3 if we find out there are too many breaking changes for devs~ this is needed as some webpack 4 issues are pretty severe

If anyone from team or community wants to jump in and point out something we are missing, both on current issues or new features we can leverage, please do :)

Let's avoid spam and "+1", we are going to delete/hide those comments

Existing issues due to webpack 4

• webpack-dev-server v3 uses chokidar 2, which breaks on Node 14+
• node file watcher problem https://github.com/quasarframework/quasar/issues/7826

New feature we want to leverage from webpack 5

• human readable chunks name
• more human readable errors?
• acorn 7.2+ update, which supports new syntax as ?? and export * as .... This should allow us to avoid using babel in some cases
• first party typings, meaning we can probably remove many @types/webpack-* packages and reduce conflicting types problems
• oob webworker support
• package "exports"
• nested tree-shaking, should help to avoid the need of import {date} from 'quasar; const { ... } = date syntax
• both ES5 and ES6 code generation
• automatic target detection via browserlist
• performance boost via persistent caching (it's opt-in)

Loaders to upgrade

• [x] autoprefixer Latest (v10.0.4) supports new plugin structure of postcss (v8). Current is v9.8.6
• [x] compression-webpack-plugin supports webpack 5 since v5, we already ship with v5.0.1. May be a good idea to update to latest anyway (v7), which drops support for webpack 4
• [x] copy-webpack-plugin supports webpack 5 since 6.0.4, we already ship with v6.3.2
• [x] css-loader supports webpack 5 since 3.3.2, we already ship with v3.6.0. May be a good idea to update to latest anyway (v5)
• [x] eslint-loader is deprecated and apparently doesn't support webpack 5. Replacing with eslint-webpack-plugin (see https://github.com/facebook/create-react-app/pull/9751), which in turn forces us to use at least ESLint 7
• [x] file-loader supports webpack 5 since 5.0, we already ship with v6.2.0 which is latest loader version
• [x] fork-ts-checker-webpack-plugin: ~we are on v4 right now, we need to upgrate to v6, webbpack 5 is there since v5~ upgraded to v6
• [ ] friendly-errors-webpack-plugin have not released a new version since 2018, and is currently not compatible with webpack 5, at least not when installed via NPM. There a fork we could use which supports v5
• [x] html-webpack-plugin: we are on v4.5 right now, v5 is currently in beta and will have webpack 5 support (and drop webpack 4 support)
• [x] mini-css-extract-plugin supports webpack 5 since 0.11 but many improvements to the support has been made in 1.x releases (latest is v1.3.1), we currently ship with v0.10
• [x] node-loader supports webpack 5 since 1.0, we already ship with v1.0.2 which is latest loader version
• [x] optimize-css-assets-webpack-plugin won't support webpack 5, its readme suggests to use css-minimizer-webpack-plugin instead
• [x] postcss-loader supports webpack 5 since v4, we currently ship with v3
• [ ] postcss-rtl Has not been updated to new plugin structure of postcss (v8). Recommend moving to rtlcss. Until we do that, we can rely on temporary fork (or create our own fork) which fixes the compatibility issues
• [ ] pug-plain-loader (used in docs) ~not updated since years, webpack 5 status support unknown. Consider using this updated fork instead~ Updated in december to support Pug 3 and webpack 5
• [x] raw-loader (used in docs) supports webpack 5 since 4.0, we already ship with v4.0.0 which is latest loader version
• [x] sass-loader supports webpack 5 since 8.0, we already ship with v10.1.0 which is latest loader version
• [x] terser-webpack-plugin supports webpack 5 since v4.2.1, we ship with v4.1.0. May be a good idea to update to latest anyway (v5.0.3)
• [ ] ts-loader ~supports webpack 5 apparently since v8.0.1, we ship with v7.0.5.~ We already ship with v8, we may consider upgrade to v9 (drops webpack v4 support and require node v12).
• [x] url-loader supports webpack 5 since 3.0, we already ship with v4.1.1 which is latest loader version
• [x] vue-loader supports webpack 5 since v15, we already ship with v15.9.5 which contains latest fix for it, nothing to do here
• [x] vue-style-loader have not released a new version since 2018. Since it was created to support SSR, and Vue3 SSR support hasn't been finished yet, this actually makes sense. Many are starting to question if that loader is still useful, I'd say we'll only know when Vue3 supports SSR
• [x] webpack-bundle-analyzer supports webpack 5 since v4.0, we already ship with v4.1.0 which is latest loader version
• [ ] webpack-chain somewhat works with webpack 5, but hasn't been updated to fully support it. Something may move in some months tho
• [x] webpack-dev-server already supports webpack 5, but have some issues which should be fixed in v4, currently in very early beta. We currently ship with v3.11
• [x] webpack-merge supports correct typings for webpack 5 since v5.3.0 (should be compatible even before that release), we ship with v4.2.2
• [x] webpack-node-externals supports webpack 5 since v2.5.0, we already ship with v2.5.2 which is latest loader version
• [ ] workbox-webpack-plugin will support webpack 5 since v6 ~(currently in RC phase)~. We should ditch v5 support and update everything to use v6 only.
• [ ] write-file-webpack-plugin should not be needed anymore since webpack-dev-server v3.1.10 which exposes a writeToDisk option. This dependency should be removed

Issues with webpack 5 migration

• ~webpack-dev-server v4 (with chokidar v3) [has been released as 4-beta.0] but there are still a number of bugs and breaking changes not applied, better wait some more time before migrating it (https://github.com/webpack/webpack-dev-server/pull/2592) https://github.com/webpack/webpack-dev-server/issues/2807~ These PRs/issues has been solved
• ~webpack-dev-server v4 uses webpack-dev-middleware v4, which contains many breaking changes~ Stable version has been released
• ~html-webpack-plugin v5 ~is currently blocked due to upstream bugs https://github.com/jantimon/html-webpack-plugin/issues/1527~ is currently in beta and will soon be released~ All upstream bugs has been fixed and v5 has been released as stable
• ~workbox-webpack-plugin v6 (lives in app-space, but we still need to add support for it in q/app) supports webpack 5 ~has not been released as stable, but it's pretty close to be~ is now stable. Down side: we must fix workbox v6 breaking changes too~
• ~vue-style-loader is many commits behind style-loader, which supports webpack 5. There is also a compatiblity issue with css-loader v4+. Critical css collection has not been tackled for Vue 3 release, and probably will in 3.1, so we're gonna switch to style-loader for now~
• webpack-chain maintainer doesn't have much more time to work on the package, this means he's not going to work on webpack 5 support on his own and rely on community efforts (pretty much 0) to perform the upgrade
• we temporarly removed postcss-safe-parser due to missing API on css-minimizer-webpack-plugin

Related issues

• [ ] https://github.com/quasarframework/quasar/issues/8064 https://github.com/quasarframework/quasar/issues/8063: upgrading compression-webpack-plugin could bring these out again
• [ ] https://github.com/quasarframework/quasar/issues/8025 https://github.com/quasarframework/quasar/issues/7954: fixed by the upgrade
• [ ] https://github.com/quasarframework/quasar/pull/8028: remove this disclaimer after the upgrade
• [ ] https://github.com/quasarframework/quasar/issues/7943: JSON files import, fixed by the upgrade
• [ ] https://github.com/quasarframework/quasar/issues/7148#issuecomment-646536358
• [ ] https://github.com/quasarframework/quasar/issues/7126 fixed by the upgrade
• [ ] https://github.com/quasarframework/quasar/issues/6530 the upgrade may help for this issue too?

Things which could be explored, but which aren't really "in-scope" for the migration

• Automatically keep in sync Webpack, TypeScript and Jest aliases
• SVG dynamic inlining https://github.com/quasarframework/quasar/issues/6027#issuecomment-573112451 https://github.com/quasarframework/quasar/issues/4763
• Somehow support web implementation of Capacitor plugins which has one
• preload support is still blocked, as both the upstream preload-webpack-plugin and the forked @vue/preload-webpack-plugin are pretty much dead. We could ask the Vue team if they plan to update their fork, as I don't think the original repo will ever come back
• WSL 2 problem with file watchers: https://github.com/microsoft/WSL/issues/4739
• fix the problems with starter kit which forces us to keep 'master' branch as default (maybe even renaming it to 'main' instead?)
• check if we can remove the need of 'core-js' dependency into user-land (difficult as it's a hoisting problem due to other packages)

Additional context Vue CLI still has not switched, but something is moving:

• https://github.com/vuejs/vue-cli/pull/5611#issuecomment-707113628
• https://github.com/vuejs/vue-cli/issues/6064
• https://github.com/vuejs/vue-cli/pull/6060

React is moving there too and have an exaustive list of stuff to upgrade and problems to solve:

• https://github.com/facebook/create-react-app/issues/9994

Angular CLI already supports Webpack 5 as experimental (we could check if we can learn something from their code), and is discussing about Module Federation feature:

• https://github.com/angular/angular-cli/pull/18820
• https://github.com/angular/angular-cli/issues/17556

[Blfrg]

Regarding:

pug-plain-loader (used in docs) not updated since years, webpack 5 status support unknown

I'm using a forked version because as you noted, it hasn't been updated for a while. The proper version by Evan has a dependency error and doesn't work with pug v3. See Other Packages in the forked readme for details.

This only depends on the latest version of loader-utils by webpack, so I believe it will be compatible. I can test/confirm once ready to review.

[IlCallo]

@Blfrg thanks, updated into the initial post :)

[yusufkandemir]

@IlCallo just a little update: workbox-webpack-plugin v6(stable) is released, and the latest version is v6.0.2.

[IlCallo]

Perfect, updated into the first post

[hawkeye64]

@IlCallo There is a temporary fork of postcss-rtl that's been upgraded to work with latest postcss plugin structure. https://www.npmjs.com/package/@mjhenkes/postcss-rtl I am thinking we may need to fork that (the form) ourselves and maintain a @quasar/postcss-rtl

[IlCallo]

I added this to the original post, but I'm not sure taking the burden of yet another package to maintain for ourselves is the right way...

[hawkeye64]

I agree. I am using rtlcss, but Razvan says that doesn't handle all of our cases properly. It may be better to PR that package with what's needed. Right now I can't say I know what is missing from rtlcss, but it is actively maintained.

[haoqunjiang]

FYI the vue fork of preload-webpack-plugin has supported webpack 5 https://github.com/vuejs/preload-webpack-plugin/releases/tag/v2.0.0 I've also maintained a fork of friendly-errors-webpack-plugin that has supported webpack 5 https://github.com/sodatea/friendly-errors-webpack-plugin/releases/tag/v1.8.0 (@soda/friendly-errors-webpack-plugin on npm)

[IlCallo]

Thanks! One or two out of the list then :D

[Blfrg]

Regarding:

pug-plain-loader (used in docs) not updated since years, webpack 5 status support unknown. Consider using this updated fork instead

I was just reviewing my dependencies and noticed that back in December @sodatea merged the needed PR for the orginal pug-plain-loader to work with pug v3.

So the original dependency can be considered reliable again, instead of the fork.

[IlCallo]

Thanks, updated in the initial list

[panhezeng]

html-webpack-plugin v5 has been upgraded to the latest stable version long ago .

[mariusa]

Just as a note, as vite support is also on roadmap: vite brings significant performance compared to webpack. After trying it, you might consider making vite a higher priority than webpack for 2.0 (speaking only from my personal experience; there could be roadblocks to using vite for other projects). Thanks for considering.

[rstoenescu]

We need to first concern about our current user base and not leave them hanging with their current apps. Due to Webpack team not upgrading chokidar dependency for Webpack 4 we can't have apps correctly running on Node 14+ (which is LTS!).

We are aware of how good Vite is, which is why we've planned a Vite plugin and even a Quasar CLI based on Vite instead of Webpack. It will come, guaranteed. I'm about to finalize the Webpack 5 upgrade (a few more days and there's going to be a q/app release with it) and then it's Vite time!

[mariusa]

Mulțumesc, Razvan :)

[rstoenescu]

"@quasar/app" v3.0.0-beta.16 will feature Webpack 5. Was hell upgrading everything (including our many of custom webpack plugins). But while I was at it, took time to also greatly improve and revamp the inner workings of q/app (and there are so many to list them here!). Get ready to rock'n'roll your apps with it!

[rstoenescu]

Available through "@quasar/app" v3.0.0-beta.16 + Quasar v2.0.0-beta.13. Enjoy and please read the release notes! https://github.com/quasarframework/quasar/releases/tag/%40quasar%2Fapp-v3.0.0-beta.16