Webpack 5 Support & 1.0 meta issue

[weaverryan]

Hi!

This issue tracks things that we want to get done before releasing a 1.0 of Encore with Webpack 5 support:

• A) Initial Webpack 5 support Update Webpack to v5 (+ other dependencies) #645
• B) Using old watchOptions regexp & removing Node 13 support [Webpack5] Using old watchOptions regexp & removing Node 13 support #878
• C) Collect changes (mostly from Update Webpack to v5 (+ other dependencies) #645) and add them to CHANGELOG Updating images and fonts to use Webpack 5 Asset modules #883
• D) Integrate Asset Modules for images, fonts, etc Updating images and fonts to use Webpack 5 Asset modules #883
• [~] E) potentially use WebpackManifestPlugin also for entrypoints.json Will consider later
• F) Check into our stats config - should we "hijack" this less and allow for more normal output?
• G) add method to enable new persistent caching - [Webpack 5] Adding new enableBuildCache() method for Webpack 5 persistent caching #884
• H) Decide on a backwards-compatibility (BC) promise related to Webpack dependencies (e.g. if we bump @babel/core from v7 to v8, does that require a new major version of Encore? OR what if we drop support for sass-loader v9 (which is a library version that the user controls) - does that require a new major version of Encore?
• I) Ideally, make all the tests that rely in hashes more forgiving - don't skip them entirely, but match for "fuzzines" - e.g. that we expect a file matching a pattern (faux example: main.[alpha length 8].js). - Updating images and fonts to use Webpack 5 Asset modules #883
• [~] J) Make a decision about friendly-errors-webpack-plugin which appears abandoned Peer Dependency issue with Webpack v5.x geowarin/friendly-errors-webpack-plugin#123 we will keep for now, it works fine, but the warning when installing Encore is annoying :/
• L) Merge new Stimulus-bridge support updating stimulus-bridge plugin to work with proposed new loader #888
• K) bumping preset-env to version that depends on @babel/plugin-proposal-class-properties #889 - bumped @babel/preset-env

[versedi]

H) Decide on a backwards-compatibility (BC) promise related to Webpack dependencies (e.g. if we bump @babel/core from v7 to v8, does that require a new major version of Encore? OR what if we drop support for sass-loader v9 (which is a library version that the user controls) - does that require a new major version of Encore?

IMHO it shouldn't rely on the major/minor update of the dependency's version, but instead on the fact if the dependency update breaks anything inside encore - eg. configuration syntax changes or behaviour of something changes.

if we bump @babel/core from v7 to v8, does that require a new major version of Encore?

Upgrade from v6 to v7 had some breaking changes IIRC in default set of plugins. I'd say it depends...

what if we drop support for sass-loader v9 (which is a library version that the user controls)

Yes. New major.

Now that I think about it, maybe the question should be - should encore try to force anything at all via versions.

From one side of the coin if it's the user's dependency he should be aware of what he's doing. From other this would require pages of changelog where anything people use is no longer supported and if not would probably cause an influx of issues.

[weaverryan]

About dependencies:

A) If we bump a major version of our direct dependencies, then would require a new major version of Encore if it can (in any reasonable way) affect our users. For example, a new version of semver would not affect our users (this is used internally for our own purposes) but a new version of babel could reasonably affect users.

B) If we bump a major version of a devDependency like sass-loader, then this is actually just a recommendation on what the user needs to have installed. Upgrading Encore does not actually upgrade their dependency. So, no new major version of Encore is needed. Of course, if we needed to change our integration with sass-loader (so that the old sass-loader will suddenly not work with the new version of Encore), then that would require a major break. In general, we would try to not "remove" support for old devDependency versions during minor Encore versions.