Update Webpack to v5 (+ other dependencies) #645

Lyrkan · 2019-10-05T00:51:07Z

Last week Webpack added a compat layer to its v5 alpha that allows the mini-css-extract-plugin to run on it (with deprecated messages). Since we include that plugin by default (and a lot of our tests relie on it) it was the main thing blocking us from preparing the migration.

I basically started from #564 which was updating some dependencies, enabling CSS HMR when needed and adding a configureMiniCssExtractPlugin(...) method, but with a few changes:

no more inconsistent hashes checks for the enableVersioning applies to js, css & manifest test: it seems to be working fine by default
no more embedding the webpack-manifest-plugin into our code: Incompatibility with the latest version of mini-css-extract-plugin (0.4.3) shellscape/webpack-manifest-plugin#167 is still an issue but @mastilver has been working on the project lately (which is why the plugin works with Webpack 5) and a fix has already been merged on the next branch, so it's probably only a matter of time now :). Edit: Fixed in webpack-manifest-plugin@^3.0.0-rc
removal of Node 8 compatibility

So now, about the state of that PR:

0 failing test left:

6 tests that will probably be fixed by Fix InnerGraph webpack/webpack#10661 in [email protected]: Uncaught Error: Error when running the browser: Error: Error when running the browser: ReferenceError: mod is not defined
~~All the 7 tests related to the vue-loader are failing with a Cannot find module 'webpack/lib/RuleSet error message (see: Webpack 5 compatibility: Missing module RuleSet vuejs/vue-loader#1599).~~
~~1 test related to the webpack-manifest-plugin issue previously mentioned~~
~~1 test related to createSharedEntry() which doesn't seem to work properly~~
~~1 test related to Babel that doesn't transform an arrow function as expected~~

A lot of deprecation notices (but most, if not all, of them are triggered by vendors), for instance:

Compilation.hooks.normalModuleLoader was moved to NormalModule.getCompilationHooks(compilation).loader
Module.id: Use new ChunkGraph API
Module.updateHash: Use new ChunkGraph API
Chunk.modulesIterable: Use new ChunkGraph API
ChunkGroup.getModuleIndex2 was renamed to getModulePostOrderIndex
Compilation.chunks was changed from Array to Set (using Array method 'reduce' is deprecated)
chunk.files was changed from Array to Set (using Array method 'reduce' is deprecated)

Some modules do not declare they are compatible with Webpack 5 yet (warning messages during yarn install): this shouldn't be an issue unless those modules require a major version upgrade to be officialy compatible (in which case breaking changes could impact us).

We're still using webpack-cli@3 which may not support Webpack 5. It currently seems to be OK but we should probably upgrade to webpack-cli@4 (currently in beta). I took a quick glance at it and it probably won't be an easy thing to do, mainly because of how our "runtime context" works and how the new version of the CLI calls Webpack (through another process).

Lyrkan · 2019-10-05T23:17:24Z

I fixed the failing Babel test which wasn't really related to Babel but to the new output.ecmaVersion option of Webpack 5.

This option tells Webpack which ES version it should use for the code it generates (for instance in JSONP callbacks) which is not transpiled by Babel.

By default it is set to 2015, meaning that it will use things like arrow functions, hence the failing test.

Since some users may not want that behavior (IE11 does not support arrow functions) I changed the default value in Encore to 5.

Regarding the deprecation messages I confirm that they are all triggered by plugins (and maybe by the Webpack core itself for some of them):

Compilation.hooks.normalModuleLoader was moved to NormalModule.getCompilationHooks(compilation).loader => mini-css-extract-plugin / vue-loader
Module.id: Use new ChunkGraph API => mini-css-extract-plugin
Module.updateHash: Use new ChunkGraph API => mini-css-extract-plugin
Chunk.modulesIterable: Use new ChunkGraph API => mini-css-extract-plugin
ChunkGroup.getModuleIndex2 was renamed to getModulePostOrderIndex => mini-css-extract-plugin
Compilation.chunks was changed from Array to Set (using Array method 'reduce' is deprecated) => mini-css-extract-plugin
chunk.files was changed from Array to Set (using Array method 'reduce' is deprecated) => webpack-manifest-plugin

Not really related but I also removed our old deprecation messages since they have all been there for a while now.

Lyrkan · 2019-10-06T21:00:59Z

It seems that the hack we are using for Encore.createSharedEntry() doesn't work anymore.

The tests are currently failing because of the following change:

optimization.splitChunks test no longer matches chunk name
MIGRATION: Use a test function (module, { chunkGraph }) => chunkGraph.getModuleChunks(module).some(chunk => chunk.name === "name")

Since we are directly checking if the chunk name matches sharedCommonsEntryName the cache group is never used and no real shared entry is created.

Sadly, after fixing that part we get the following error message:

BREAKING CHANGE: webpack < 5 used to allow to use the entrypoint as splitChunk. This is no longer allowed. Remove this entrypoint and add modules to cache group's 'test' instead.
If you need modules to be evaluated on startup, add them to the existing entrypoints (make them arrays). See migration guide of more info.

Which is exactly how Encore.createSharedEntry() works:

webpack-encore/lib/config-generator.js

Lines 517 to 527 in 5640271

    
           cacheGroups[this.webpackConfig.sharedCommonsEntryName] = { 
        
               chunks: 'initial', 
        
               name: this.webpackConfig.sharedCommonsEntryName, 
        
               // important: setting this to the entry name means that 
        
               // all modules included by that entry go into this cache group 
        
               test: this.webpackConfig.sharedCommonsEntryName, 
        
               // seems to default the rest of the options (like minSize) 
        
               // to settings so that modules matched by "test" are 
        
               // *definitely* included. 
        
               enforce: true, 
        
           };

Kocal · 2019-10-07T07:19:44Z

Is there still a legitimate reason to use/have Encore.createSharedEntry()?

Lyrkan · 2019-10-07T08:09:20Z

@Kocal I'd say that it's useful for people that are not using the Encore Bundle since they can't predict the names of the shared chunks Webpack will generate for them when using splitEntryChunks().

stof · 2019-10-07T09:40:55Z

index.js

+     * @param {function} pluginOptionsCallback
+     * @returns {Encore}
+     */
+    configureMiniCssExtractPlugin(loaderOptionsCallback, pluginOptionsCallback = () => {}) {


should this be bundled in the webpack 5 upgrade, or be submitted separately ?

I originally added it into #564 in case people wanted to disable the new hmr option (which is also included in this one). So, maybe we could ship it separately but it'd be preferable if it was done before the mini-css-extract-plugin upgrade.

stof · 2019-10-07T09:45:41Z

test/WebpackConfig.js

@@ -546,7 +546,7 @@ describe('WebpackConfig object', () => {

        it('Calling with "includeNodeModules" option', () => {
            const config = createConfig();
-            config.configureBabel(() => {}, { include_node_modules: ['foo', 'bar'] });
+            config.configureBabel(() => {}, { includeNodeModules: ['foo', 'bar'] });


should already be done in the existing version

I remember keeping the include_node_modules check on purpose since we only deprecated that version. But maybe we should have had an additional check for the uppercase version.

stof · 2019-10-07T09:46:12Z

test/bin/encore.js

@@ -39,6 +39,7 @@ describe('bin/encore.js', function() {
            `
 const Encore = require('../../index.js');
 Encore
+    .enableSingleRuntimeChunk()


shouldn't this be done in the existing version already ?

We could but that's not a big issue since the current version allows not to call enableSingleRuntimeChunk()/disableSingleRuntimeChunk() (unless you also called createSharedEntry() it defaults to the disableSingleRuntimeChunk() behavior with deprecation messages).

I mean, we should avoid using deprecated API in our testsuite, unless we are specifically testing the BC layer (in which case the test gets removed when dropping it, or changed to a test asserting an exception).
That's the policy we have in Symfony itself (we even make the testsuite fail if deprecations are triggered in non-legacy tests).

weaverryan · 2019-10-07T18:57:29Z

About createSharedEntry(), I think we should try this (and see how it looks/feels):

A) Remove createSharedEntry() (if we like the final solution, we can deprecate it in a Webpack4-supporting Encore release before releasing this)

B) Replace it with some interface to make it easier/obvious to the user to add their own cache group - e.g. to get some end-config that looks similar to this: https://webpack.js.org/plugins/split-chunks-plugin/#split-chunks-example-3

It could be something like:

.addCacheGroup('vendor', {
    test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/,
})

That would be the lowest-level way to handle this. We might choose to instead/also add something more user-friendly:

.addCacheGroup('vendor', {
    # could be an optional "key" we add... the user could use this *or* test (but not both)
    node_modules: ['react', 'react-dom'],

    # or another possibility, where we allow mixing "node_modules" modules and also specific paths
    modules: ['react', 'react-dom', './assets/js/main'],
})

Not sure how far we need to go. If we did the first and added good documentation with a "vendors" example, that will go a long way.

Lyrkan · 2019-10-24T20:49:32Z

Updated the PR with webpack@^5.0.0-beta and webpack-manifest-plugin@^3.0.0-rc:

Incompatibility with the latest version of mini-css-extract-plugin (0.4.3) shellscape/webpack-manifest-plugin#167 is now fixed and everything seems to be working fine with Webpack 5 :)
Webpack has bumped its minimum requirement for Node's version to 10.13.0, I haven't changed our test matrix yet but I can't see a reason not to do it since Node 8 goes EOL at the end of the year anyway.
I opened an issue on vue-loader's repository about the webpack/lib/RuleSet thing that makes it incompatible with Webpack 5 (Webpack 5 compatibility: Missing module RuleSet vuejs/vue-loader#1599)
I like the addCacheGroup() idea to replace createSharedEntry(), I might give it a shot soon

…createSharedEntry() (Lyrkan) This PR was squashed before being merged into the master branch (closes #680). Discussion ---------- Add Encore.addCacheGroup() method and depreciate Encore.createSharedEntry() As discussed in #645 (comment) our `Encore.createSharedEntry()` hack won't work anymore with Webpack 5. Since it was mostly something that was added to make the transition from Webpack 3 to Webpack 4 less painful it's probably time to depreciate it and encourage people to use cache groups properly instead. This PR adds a new `Encore.addCacheGroup()` method that, as its name implies, simply adds a new cache group to the config: ```js Encore.addCacheGroup('vendor', { test: /[\\/]node_modules[\\/]react/ }); ``` To make it a bit easier in case people want to directly reference things from the `node_modules` directory I also added a `node_modules` option which is basically a shorthand that sets the `test` option: ```js Encore.addCacheGroup('vendor', { node_modules: ['react', 'react-dom'] }); ``` Commits ------- 7e32b0b Add a warning when calling addCacheGroup() with 'vendors' or the same than in createSharedEntry() e4095b3 Add Encore.addCacheGroup() method and depreciate Encore.createSharedEntry()

Lyrkan · 2020-04-16T11:43:19Z

PR updated:

I bumped the version of a few dependencies (including webpack and vue)
The issue we previously had with Vue.js has been fixed
I removed createSharedEntry() since we already deprecated it in master
Node 8 does not work anymore with some loaders, so I removed it from our test matrix

There are some new failing tests, but they are all caused by the same thing and should be fixed in the next release of Webpack (see webpack/webpack#10661).

weaverryan · 2020-04-17T10:24:52Z

Awesome @Lyrkan! Thanks for keeping this up to date - we should be able to get Encore released fast once Webpack gets here - whenever that is :).

lib/friendly-errors/transformers/missing-loader.js

Lyrkan · 2020-05-10T23:48:24Z

test/functional.js

+                const isVue2 = getVueVersion(config) === 2;
+                config.addCacheGroup('vuejs', {
+                    test: isVue2 ?
+                        /[\\/]node_modules[\\/]vue[\\/]/ :
+                        /[\\/]node_modules[\\/]@vue[\\/]/
+                });


Quick explanation about why this is needed.
This is actually not directly related to Webpack 5 but because of how vue is now splitted into multiple packages under the @vue scope.

The imported module when you import vue does not do much:

import { warn } from '@vue/runtime-dom'; export * from '@vue/runtime-dom'; // This entry exports the runtime only, and is built as const compile = () => { if ((process.env.NODE_ENV !== 'production')) { warn(`Runtime compilation is not supported in this build of Vue.` + ( ` Configure your bundler to alias "vue" to "vue/dist/vue.esm-bundler.js".` ) /* should not happen */); } }; export { compile };

With Webpack 4 the cache group seemed to worked because it created a shared file with the code of the compile function and the declaration of the multiple exports from @vue/runtime-dom (without their actual code... so not really useful).

With Webpack 5 I'm guessing that the compile function gets tree shaken and nothing matches the node_modules/vue test of the cache group anymore and no shared file is created.

Lyrkan · 2020-12-03T16:34:53Z

Everything should be good now!

The failing tests are unrelated (probably introduced by #865 since we use the sass-loader version in them).

weaverryan · 2020-12-20T14:07:34Z

@Lyrkan could you fix up the yarn.lock conflict one more time? Thanks!

weaverryan

I'm still reviewing, but it's looking really good so far!

package.json

fixtures/js/shared_example.js

weaverryan · 2020-12-20T16:52:41Z

index.js

-    configureOptimizeCssPlugin(optimizeCssPluginOptionsCallback = () => {}) {
-        webpackConfig.configureOptimizeCssPlugin(optimizeCssPluginOptionsCallback);
+    configureCssMinimizerPlugin(cssMinimizerPluginOptionsCallback = () => {}) {
+        webpackConfig.configureCssMinimizerPlugin(cssMinimizerPluginOptionsCallback);


We'll need to summarize these changes in the CHANGELOG. If you could bootstrap that, it would be awesome - but I can also do it later.

lib/config-generator.js

weaverryan · 2020-12-20T16:59:31Z

lib/config-generator.js

-        } else {
-            // see versioning.js: this gives us friendly module names,
-            // which can be useful for debugging, especially with HMR
-            optimization.namedModules = true;


This is related to the versioning.js above. Why is this not needed now? Is it the default? thx for the explanation :)

optimization.namedModules has been replaced by optimization.moduleIds: 'named': https://webpack.js.org/migrate/5/#update-outdated-options

This is the default value for development builds: https://webpack.js.org/configuration/mode/#mode-development

weaverryan · 2020-12-20T17:00:33Z

lib/config-generator.js

@@ -632,7 +542,7 @@ class ConfigGenerator {

    buildWatchOptionsConfig() {
        const watchOptions = {
-            ignored: /node_modules/
+            ignored: 'node_modules'


Can you explain this change?

When I did that change using a RegExp was not allowed for that option anymore.

It seems that it was added back by webpack/webpack#11498.

I see it! We should probably change this back then?

FYI - this has been reverted

weaverryan

Review complete! This is really nice, and it deletes more code than it adds - always wonderful :). There is one significant thing that I'm wondering about for Webpack 5 - Asset Modules - https://webpack.js.org/guides/asset-modules/

It seems like using file-loader, url-loader, etc for images, fonts, etc is now "non-standard", and instead we should use Asset Modules. If I'm correct, ideally we would refactor to use that immediately so that we can use the breaking changes in the release to remove file-loader, url-loader, etc. But, we could do this in a different PR.

A few other things I'm thinking about:

A) I'm wondering if we could start using webpack-manifest-plugin also to generate the entrypoints.json file. I have no tried it yet, but the idea would be to use the useEntryKeys option. This would mean we would need to use the plugin 2 times... once for manifest.json and again for entrypoints.json... which I think is ok, but a bit non-standard. We might also (but not sure) need to remove or move the "sha-" checksums - I'm not sure if those could be done with webpack-manifest-plugin

B) A lot of defaults were changed on stats. We should revisit if we can remove much/all of our "overriding" and allow encore to have a more standard output.

C) Finally, it might be nice to have a new method for the persistent caching - maybe .enableBuildCache(), with some config to allow them to add more files / configure the cache. We could, by default, at least add webpack.config.js to the cache... so it "should" work out of the box for most users.

Cheers!

test/functional.js

Lyrkan · 2020-12-22T07:05:12Z

There is one significant thing that I'm wondering about for Webpack 5 - Asset Modules - webpack.js.org/guides/asset-modules

It seems like using file-loader, url-loader, etc for images, fonts, etc is now "non-standard", and instead we should use Asset Modules. If I'm correct, ideally we would refactor to use that immediately so that we can use the breaking changes in the release to remove file-loader, url-loader, etc. But, we could do this in a different PR.

Hm, I kept file-loader and url-loader to avoid adding other sudden breaking changes.
Both of them still work and we'll actually still need the file-loader for Encore.copyFiles().
I think we could try to progressively remove them later, maybe by using asset modules by default unless the user calls configureUrlLoader(...).

A) I'm wondering if we could start using webpack-manifest-plugin also to generate the entrypoints.json file. I have no tried it yet, but the idea would be to use the useEntryKeys option. This would mean we would need to use the plugin 2 times... once for manifest.json and again for entrypoints.json... which I think is ok, but a bit non-standard. We might also (but not sure) need to remove or move the "sha-" checksums - I'm not sure if those could be done with webpack-manifest-plugin

Hm, I haven't really thought about that to be honest, in my opinion both plugins do different things.
For the checksums I know that it could now be done automatically by the assets-webpack-plugin (that wasn't the case when we added that feature), but not with the same format than the one we currently have.

B) A lot of defaults were changed on stats. We should revisit if we can remove much/all of our "overriding" and allow encore to have a more standard output.

👍

C) Finally, it might be nice to have a new method for the persistent caching - maybe .enableBuildCache(), with some config to allow them to add more files / configure the cache. We could, by default, at least add webpack.config.js to the cache... so it "should" work out of the box for most users.

Things can easily go wrong with persistent caching... even only enabling it for the config file could lead to some issues if not done properly (for instance if the config use values coming from environment variables, which is far from an edge case imo: https://github.com/webpack/changelog-v5/blob/master/guides/persistent-caching.md#version).

I also think that we should provide some way to enable/configure it in Encore but that should probably be treated separately after thinking for a while about how we really want to handle that.

weaverryan · 2020-12-31T20:09:31Z

Hm, I kept file-loader and url-loader to avoid adding other sudden breaking changes.
Both of them still work and we'll actually still need the file-loader for Encore.copyFiles().

The migration page - https://webpack.js.org/migrate/5/ - suggests that we should migrate away to use asset modules:

Several commonly-used loaders like raw-loader, url-loader, and file-loader should be replaced using the new built-in Asset Modules feature.

So, I think we should make this change now (or at least try it). However, we can do it in another PR after we merge this. And we can keep using file-loader for Encore.copyFiles() - I don't see any issue with that.

Hm, I haven't really thought about that to be honest, in my opinion both plugins do different things.
For the checksums I know that it could now be done automatically by the assets-webpack-plugin (that wasn't the case when we added that feature), but not with the same format than the one we currently have.

It's something we can investigate after we merge this PR. If we can make Encore smaller and more standard, cool :)

I also think that we should provide some way to enable/configure it in Encore but that should probably be treated separately after thinking for a while about how we really want to handle that.

Concerns heard! Let's definitely consider it in another PR. It would be a nice "sweet new feature!" to have when we release the Webpack5-powered Encore ;).

weaverryan · 2020-12-31T20:10:48Z

Thank you for this HUGE work @Lyrkan! A PR created more than 1 year agoto track Webpack 5, and now I caan happily merge it :). I will create an issue to track the final few things that we're considering before releasing this new Webpack-5-powered version. Thanks!

Edit: Issue is #880

Kocal · 2020-12-31T20:34:12Z

Nice!! :D

… 13 support (weaverryan) This PR was squashed before being merged into the main branch. Discussion ---------- [Webpack5] Using old watchOptions regexp & removing Node 13 support 2 quick, minor follow-ups from #645. * Removed Node 13, as it is no longer supported * Changed the ignored back to a regular expression, which it was originally and once again a regexp works: #645 (comment) * Upgraded to Stimulus 2, which the stimulus bridge now depends on Commits ------- 816003e updating hashes for latest deps ad714b7 upgrading to stimulus 2 3a4005c upgrading deps 4e0aa70 fixing tests 3c43cea removing support for Node 13 343a4fe changing watch options ignored back to a regexp to match previous behavior

… (weaverryan) This PR was squashed before being merged into the main branch. Discussion ---------- Updating images and fonts to use Webpack 5 Asset modules This is one more big piece for proper Webpack 5 support - see #880 This also updates the CHANGELOG both for this PR and for the original in #645 And, this adds a new assertion method that helps check directory contents in functional.js in a way that is more resilient to hash changes. For the most part... this just worked! See the CHANGELOG. Because this will release on 1.0, I have decided to remove a few methods instead of deprecating them ). Cheers! Commits ------- 55495cf changing the default to asset/resource a663fbc moving require into loader function 8d3b401 fixing tests on the lowest deps due to version upgrades 3e9c787 Making tests more resilient to failure by fuzzy checking some hash filenames d86e115 upgrading Webpack min 64c6c2f updating CHANGELOG for original Webpack 5 changes in #645 16c0f12 Updating images and fonts to use Webpack 5 Asset modules

@Lyrkan

…pack 5 persistent caching (weaverryan) This PR was squashed before being merged into the main branch. Discussion ---------- [Webpack 5] Adding new enableBuildCache() method for Webpack 5 persistent caching Hi! This is a very simple feature, but it can also easily be improperly used. It is part of #880. See some comments about it from @Lyrkan from #645: > Things can easily go wrong with persistent caching... even only enabling it for the config file could lead to some issues if not done properly (for instance if the config use values coming from environment variables, which is far from an edge case imo: https://github.com/webpack/changelog-v5/blob/master/guides/persistent-caching.md#version). The trick, for us, is to: A) Make sure we are doing everything as correctly as we can. For example, I assume that WE don't need to include `.babelrc` or `postcss.config.js`, but I actually don't know that for sure. Should we also potentially be adding Encore itself to the build dependencies? B) Good communication in the documentation above the method and in the (eventual) recipe where we include this in the user's webpack.config.js file ## TODO * [ ] 1) Test in a real project to see if we're missing anything (also play with what the valid keys are under `buildDependencies` - other than `config`, this is not documented anywhere). * [x] ~~2) Check into Stimulus: I'm curious if `controllers.json` will need to be added to the build dependencies. I'm also curious if the UX vendor libraries will need to be in the build dependencies, as these do not follow the normal versioning (i.e. their directories in `node_modules/` can change without a change to `yarn.lock` or `package.json`)~~ should be solved by linked changes in #888 Cheers! Commits ------- a592c82 lint 9f117a4 fixing test 7a39654 Adding new enableBuildCache() method for Webpack 5 persistent caching

This PR was merged into the main branch. Discussion ---------- Allow node 10.19 This was bumped in #645 Ubuntu LTS [ships node 10.19](https://packages.ubuntu.com/focal/nodejs) by default. If we can, let's save ppl (aka me) from installing yet another ppa. Commits ------- 7721aa2 Allow node 10.19

Lyrkan requested a review from weaverryan October 5, 2019 00:56

This was referenced Oct 5, 2019

[WIP] Use mini-css-extract-plugin@^0.7.0 and embed webpack-manifest-plugin into Encore #564

Closed

Browser sync #145

Closed

Lyrkan force-pushed the webpack5 branch from e4e9c27 to 24c20b2 Compare October 5, 2019 21:44

Lyrkan mentioned this pull request Oct 6, 2019

Add output.ecmaVersion to configuration changes webpack/changelog-v5#3

Closed

stof reviewed Oct 7, 2019

View reviewed changes

Atlanta mentioned this pull request Oct 18, 2019

Support for sass-loader 8.0.0 #654

Closed

Lyrkan force-pushed the webpack5 branch from cec2405 to 2f9783b Compare October 24, 2019 20:29

Lyrkan mentioned this pull request Dec 16, 2019

Add Encore.addCacheGroup() method and depreciate Encore.createSharedEntry() #680

Merged

Lyrkan mentioned this pull request Feb 21, 2020

How to configure mini-css-extract-plugin #701

Open

Lyrkan force-pushed the webpack5 branch 4 times, most recently from 37e9ea3 to beb34ac Compare April 16, 2020 11:34

Lyrkan force-pushed the webpack5 branch 2 times, most recently from f8b84f9 to 4576fc3 Compare April 24, 2020 10:52

Lyrkan mentioned this pull request Apr 29, 2020

mini-css-extract-plugin is totally outdated #742

Closed

Lyrkan force-pushed the webpack5 branch from 4576fc3 to eabc6fe Compare May 10, 2020 23:32

Lyrkan commented May 10, 2020

View reviewed changes

stof mentioned this pull request Jun 25, 2020

add Elm support to webpack encore #793

Closed

b1rdex mentioned this pull request Jul 13, 2020

Webpack 5 beta 22 Lyrkan/webpack-encore#1

Closed

Lyrkan added 3 commits December 3, 2020 17:11

Update WebpackManifestPlugin to v3.0.0 and vue-loader to v16.1.0

4f6171b

Update some hashes in functional tests

b0f7190

Remove deprecation caused by the DeletedUnusuedEntriesJSPlugin

d576b21

Lyrkan force-pushed the webpack5 branch from 66ac74d to d576b21 Compare December 3, 2020 16:11

Fix linting issues

b292e76

Lyrkan marked this pull request as ready for review December 3, 2020 16:22

Merge branch 'main' into webpack5

444c37f

weaverryan reviewed Dec 20, 2020

View reviewed changes

weaverryan reviewed Dec 21, 2020

View reviewed changes

test/functional.js Show resolved Hide resolved

test/functional.js Outdated Show resolved Hide resolved

test/functional.js Show resolved Hide resolved

Lyrkan added 4 commits December 22, 2020 06:49

Merge branch 'main' into webpack5

ddcd6d8

Update css-loader and style-loader

216a5ca

Add removed Babel test back

8d7843a

Remove unusued files/constants related to versioning/shared entry

57f64fa

weaverryan merged commit a27a476 into symfony:main Dec 31, 2020

weaverryan mentioned this pull request Dec 31, 2020

[Webpack5] Using old watchOptions regexp & removing Node 13 support #878

Merged

weaverryan mentioned this pull request Dec 31, 2020

Webpack 5 Support & 1.0 meta issue #880

Closed

10 tasks

weaverryan mentioned this pull request Jan 9, 2021

Updating images and fonts to use Webpack 5 Asset modules #883

Merged

weaverryan added a commit to weaverryan/webpack-encore that referenced this pull request Jan 10, 2021

updating CHANGELOG for original Webpack 5 changes in symfony#645

64c6c2f

weaverryan mentioned this pull request Jan 11, 2021

[Webpack 5] Adding new enableBuildCache() method for Webpack 5 persistent caching #884

Merged

2 tasks

nicolas-grekas mentioned this pull request Feb 3, 2021

Allow node 10.19 #912

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update Webpack to v5 (+ other dependencies) #645

Update Webpack to v5 (+ other dependencies) #645

Lyrkan commented Oct 5, 2019 •

edited

Loading

Lyrkan commented Oct 5, 2019 •

edited

Loading

Lyrkan commented Oct 6, 2019

Kocal commented Oct 7, 2019 •

edited

Loading

Lyrkan commented Oct 7, 2019

stof Oct 7, 2019

Lyrkan Oct 7, 2019

stof Oct 7, 2019

Lyrkan Oct 7, 2019

stof Oct 7, 2019

Lyrkan Oct 7, 2019

stof Oct 7, 2019

weaverryan commented Oct 7, 2019

Lyrkan commented Oct 24, 2019

Lyrkan commented Apr 16, 2020 •

edited

Loading

weaverryan commented Apr 17, 2020

Lyrkan May 10, 2020 •

edited

Loading

Lyrkan commented Dec 3, 2020

weaverryan commented Dec 20, 2020

weaverryan left a comment

weaverryan Dec 20, 2020

weaverryan Dec 20, 2020

Lyrkan Dec 22, 2020

weaverryan Dec 20, 2020

Lyrkan Dec 22, 2020

weaverryan Dec 31, 2020

weaverryan Jan 9, 2021 •

edited

Loading

weaverryan left a comment

Lyrkan commented Dec 22, 2020

weaverryan commented Dec 31, 2020

weaverryan commented Dec 31, 2020 •

edited

Loading

Kocal commented Dec 31, 2020

Update Webpack to v5 (+ other dependencies) #645

Update Webpack to v5 (+ other dependencies) #645

Conversation

Lyrkan commented Oct 5, 2019 • edited Loading

Lyrkan commented Oct 5, 2019 • edited Loading

Lyrkan commented Oct 6, 2019

Kocal commented Oct 7, 2019 • edited Loading

Lyrkan commented Oct 7, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weaverryan commented Oct 7, 2019

Lyrkan commented Oct 24, 2019

Lyrkan commented Apr 16, 2020 • edited Loading

weaverryan commented Apr 17, 2020

Lyrkan May 10, 2020 • edited Loading

Choose a reason for hiding this comment

Lyrkan commented Dec 3, 2020

weaverryan commented Dec 20, 2020

weaverryan left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

weaverryan Jan 9, 2021 • edited Loading

Choose a reason for hiding this comment

weaverryan left a comment

Choose a reason for hiding this comment

Lyrkan commented Dec 22, 2020

weaverryan commented Dec 31, 2020

weaverryan commented Dec 31, 2020 • edited Loading

Kocal commented Dec 31, 2020

Lyrkan commented Oct 5, 2019 •

edited

Loading

Lyrkan commented Oct 5, 2019 •

edited

Loading

Kocal commented Oct 7, 2019 •

edited

Loading

Lyrkan commented Apr 16, 2020 •

edited

Loading

Lyrkan May 10, 2020 •

edited

Loading

weaverryan Jan 9, 2021 •

edited

Loading

weaverryan commented Dec 31, 2020 •

edited

Loading