webpack 5 alpha feedback

🎄 First, thanks for trying and giving feedback to our alpha version. 🎄
Note that it's still in an early state and stuff may be broken. This is something you want to report here, as we don't want this to happen in the final release.
Note that the major version has breaking changes and some plugins might no longer work as expected. We try to provided compatibility layers when possible, but some of the changes make this difficult (especially regarding injection additional runtime code). If some plugin isn't working this is also something you should report here to we are at least aware of it and may work on fixing it or adding a compatibility layer.
Here is the full Changelog. Make sure to read at least until the configuration changes to be up-to-date.
If you find something missing in the changelog, this is also something to report here. Easy fixes can made directly in the repo. Every webpack contributor has write access, otherwise send a PR.
If everything is working great, that's also nice to hear. If you are trying the Persistent Caching feature, we would love to see numbers.
Please make sure to try with the lastest alpha version before reporting, as it may already be fixed. You can use the npm dist-tag next to reference the latest alpha version.
package.json "webpack": "next". Update with yarn upgrade webpack / npm update webpack.
Not to forget: Thanks for everybody contributed to this version (@byzyk, @cacheflow, @Connormiha, @fscherwi, @guybedford, @michael-ciniawsky, @niieani, @ooflorent, @SevInf, @smelukov, @sodatea, @sokra, @xtuc). 🎉

Feedback summary:

[ ] mini-css-extract-plugin is incompatible (RuntimeModules change)
[ ] fork-ts-checker-webpack-plugin is incompatible (frozen hooks)
[ ] circular-dependency-plugin is incompatible (dep.module removed)
[x] cache-loader is no longer needed
[ ] webpack-cli misses Stats.presetToOptions (should use compilation.createStatsOptions)
[ ] html-webpack-plugin misses fileTimestamps (should use fileSystemInfo)

mini-css-extract-plugin is broken because mainTemplate.hooks.requireEnsure is removed from web pack 5, seems I can fix the problem by replacing it with mainTemplate.hooks.requireExtensions. Wondering what's your plan with mini-css-extract-plugin.

Wondering what's your plan with mini-css-extract-plugin.

We will update mini-css-extract-plugin. There are a few new features in webpack 5 that can be now used by the mini-css-extract-plugin: size info for styles, HMR, RuntimeModule for the css loading logic

@sokra Is cache-loader not needed anymore? Build still works but I see no performance difference. It is actually a bit slower with cache-loader.
Overall, we are noticing improved build speeds just by enabling the new cache. No problems besides the Node stuff. 👍

Is cache-loader not needed anymore?

When using the Persistent Cache, you don't need the cache-loader anymore. Same for babel cacheDirectory.

Great work @sokra! Is there an upgrade guide for plugin / loader authors available? The webpack 5 equivalent of
https://medium.com/webpack/webpack-4-migration-guide-for-plugins-loaders-20a79b927202
Or https://blog.johnnyreilly.com/2018/01/finding-webpack-4-use-map.html
?

Is there an upgrade guide for plugin / loader authors available?

There is a section to this in the bottom half of the changelog, but it could probably need some more love.

Trying on a few different project this evening. So far so good. Will make sure to give a detailed before and after. QQ - do webpackChunkNames work the same way?
`Module parse failed: Unexpected token (7:27)
You may need an appropriate loader to handle this file type.
|   return new Promise(function ($return, $error) {
|     var mod;

return Promise.resolve(import(

|     /* webpackChunkName: "graphql" */
|     './graphql')).then(function ($await_3) {
@ ../src/javascripts/index.js 14:0-36 86:22-29`

Apologies have re-read the changelog. Great work everyone 👍

do webpackChunkName work the same way?

yes

Feedback:

IgnorePlugin:
Original: new webpack.IgnorePlugin(regex)
Build error: ValidationError: IgnorePlugin Invalid Options options should match exactly one schema in oneOf
Solution: new webpack.IgnorePlugin({ resourceRegExp: regex })

NamedChunksPlugin
Original: new webpack.NamedChunksPlugin()
Build error: webpack.NamedChunksPlugin is not a constructor
Solution: optimization: { chunkIds: 'named' }

mini-css-extract-plugin
Error: Cannot read property 'tap' of undefined
Solution: (remove plugin for now)

circular-dependency-plugin
Error: module property was removed from Dependency (use compilation.moduleGraph.getModule(dependency) instead)
Solution: (remove plugin for now)

Runtime error: ReferenceError: Can't find variable: global (jss dependency)
Solution: new webpack.ProvidePlugin({  global: require.resolve('./global') })
global.js: module.exports = window

1, 2, 5: added notes to the changelog
regarding 5: you could also set node.global: true.

I presume 5.0 will essentially make hard-source-webpack-plugin obsolete.
If that's the case, is there a comparison in terms of performance?

Regarding webpack-cli: Try to pass stats: { preset: "verbose" } instead of stats: "verbose" until this is fixed (similar for other string or boolean arguments).

webpack-cli misses Stats.presetToOptions (should use compilation.createStatsOptions) any feedback on this? Also, send an issue to webpack-cli.
For v5 can we have stats.assets <Array> have the paths to their original source? It would be nice to compare % metrics with performance

Crash after editing a JS file while webpack-dev-server watches for changes:
const timestamp = fileTimestamps.get(fileDependency);
TypeError: Cannot read property 'get' of undefined
    at childCompiler.fileDependencies.some (/node_modules/html-webpack-plugin/lib/compiler.js:341:38)

webpack-dev-server: 3.1.12 and html-webpack-plugin: 4.0.0-beta.5

Those looking to track the fork-ts-checker-webpack-plugin compatibility should follow the excellent @liangchunn's PR: https://github.com/Realytics/fork-ts-checker-webpack-plugin/pull/166
We're at the point of having working code.  We're likely to make some internal refinements and then push out an alpha. Thanks @sokra for providing advice!
The super enthusiastic can take the WIP branch for a tour here: https://github.com/liangchunn/fork-ts-checker-webpack-plugin/tree/feature/webpack5

@sokra - could you provide some details of Compilation.fileSystemInfo please?  I've been digging around but I can't find any information about it.  I want to switch ts-loader from using fileTimestamps to fileSystemInfo but need more information about the API of fileSystemInfo in order that I can do that.
Thanks!

@johnnyreilly You can call compilation.fileSystemInfo.getFileTimestamp(path, callback) to get the timestamp info of a file. It's async compared to the old API. It gives an object with { safeTime: number, timestamp: number }. safeTime is something you can compare with Date.now() (it includes an additional margin for fs accuracy). timestamp is something you store and compare with itself (you can't trust it because of fs accuracy). In future there will be a getFileHash(path, callback) methods which gives you a hash of the file content, but this is not implemented yet.

Thanks @sokra!
As it turns out, I think ts-loader may be good as is.  It uses Compiler.fileTimestamps and not Compilation.fileTimestamps.  Easy mistake to make 😄
However I think the info you've provided will be super useful for @jantimon when he's looking at html-webpack-plugin 👍

I tried in our main app and got this:
> looop@ fe /home/capaj/git_projects/looop/project-alpha
> cd ./front-end && node dev-server

NODE_ENV:  development
/home/capaj/git_projects/looop/project-alpha/node_modules/html-webpack-plugin/index.js:59
        compilation.hooks.htmlWebpackPluginAlterChunks = new SyncWaterfallHook(['chunks', 'objectWithPluginRef']);
                                                       ^

TypeError: Cannot add property htmlWebpackPluginAlterChunks, object is not extensible
    at compiler.hooks.compilation.tap.compilation (/home/capaj/git_projects/looop/project-alpha/node_modules/html-webpack-plugin/index.js:59:56)
    at SyncHook.eval [as call] (eval at create (/home/capaj/git_projects/looop/project-alpha/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:9:1)
    at SyncHook.lazyCompileHook (/home/capaj/git_projects/looop/project-alpha/node_modules/tapable/lib/Hook.js:154:20)
    at Compiler.newCompilation (/home/capaj/git_projects/looop/project-alpha/node_modules/webpack/lib/Compiler.js:527:26)
    at hooks.beforeCompile.callAsync.err (/home/capaj/git_projects/looop/project-alpha/node_modules/webpack/lib/Compiler.js:567:29)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/capaj/git_projects/looop/project-alpha/node_modules/tapable/lib/HookCodeFactory.js:32:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/home/capaj/git_projects/looop/project-alpha/node_modules/tapable/lib/Hook.js:154:20)
    at Compiler.compile (/home/capaj/git_projects/looop/project-alpha/node_modules/webpack/lib/Compiler.js:562:28)
    at compiler.hooks.watchRun.callAsync.err (/home/capaj/git_projects/looop/project-alpha/node_modules/webpack/lib/Watching.js:107:19)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/capaj/git_projects/looop/project-alpha/node_modules/tapable/lib/HookCodeFactory.js:32:10), <anonymous>:15:1)
    at AsyncSeriesHook.lazyCompileHook (/home/capaj/git_projects/looop/project-alpha/node_modules/tapable/lib/Hook.js:154:20)
    at compiler.cache.endIdle.err (/home/capaj/git_projects/looop/project-alpha/node_modules/webpack/lib/Watching.js:70:33)
    at AsyncParallelHook.eval [as callAsync] (eval at create (/home/capaj/git_projects/looop/project-alpha/node_modules/tapable/lib/HookCodeFactory.js:32:10), <anonymous>:6:1)
    at AsyncParallelHook.lazyCompileHook (/home/capaj/git_projects/looop/project-alpha/node_modules/tapable/lib/Hook.js:154:20)
    at Cache.endIdle (/home/capaj/git_projects/looop/project-alpha/node_modules/webpack/lib/Cache.js:39:22)
    at Watching._go (/home/capaj/git_projects/looop/project-alpha/node_modules/webpack/lib/Watching.js:68:23)

any pointers?

Crash after editing a JS file while webpack-dev-server watches for changes:
const timestamp = fileTimestamps.get(fileDependency);
TypeError: Cannot read property 'get' of undefined
    at childCompiler.fileDependencies.some (/node_modules/html-webpack-plugin/lib/compiler.js:341:38)

webpack-dev-server: 3.1.12 and html-webpack-plugin: 4.0.0-beta.5

Can anyone please give me some hints how and why the timestamps api changed?
I am using it here to find out wether the html template has to be recompiled.
For webpack 4 it just loops over all compilation file dependency timestamps.
Is getFileTimestamp as fast as that look up or will it add an additional fs lookup?

Got some performance results for webpack 4 vs webpack 5 alpha.
Summary:
For incremental builds Webpack 5 is defenitely faster than Webpack 4! 👍👍
The larger your project the bigger the performance gains.
Tests:

All builds
Incremental Typescript 100 components 15% faster than webpack 4
Incremental Typescript 1000 components 32% faster than webpack 4
Incremental Babel 100 components 12% faster than webpack 4
Incremental Babel 1000 components 29% faster than webpack 4

Profiles:

@jantimon
Can't seem to reproduce locally. webpack-dev-server is giving me errors but I've tried digging but to no avail. Any pointers?
webpack-config-plugins/performance on  webpack-5-speed-test [!] is 📦 ⚠ via ⬢ v10.13.0 took 57s
➜ transpiler=typescript moduleMultiplier=10 node measure-dev-server.js
Running measurments for typescript 10
🎁  Packing current packages
🗑  Removing packages for current
💿  Installing packages for current

------------------------------
🚀 Start current
------------------------------

Starting type checking service...
Using 2 workers with 2048MB memory limit
ℹ ｢wds｣: Project is running at http://localhost:8080/
ℹ ｢wds｣: webpack output is served from /
No type errors found
Version: typescript 3.2.2
Time: 16148ms
ℹ ｢wdm｣: Failed to compile.

If you want to include a polyfill, you need to install 'url'.
If you don't want to include a polyfill, you can use an empty module like this:
	resolve.alias: { "url": false }

Thanks for the hint I fixed that :)
please try again

@jantimon

For incremental builds Webpack 5 is definitely slower than Webpack 4
The larger your project the bigger the performance loss.

Just a quick CHANGELOG look; I noticed some arraysare changed to sets.  I'm wondering if the nodejs version you're running is missing new improvements to sets, or arrays are simply faster?  (Not sure how big those sets/arrays can be...)

According to @jantimon he was running on:
$ node --version
v10.14.2

So it can't be that I think

@sokra Hey. I try to test<EMAIL_ADDRESS>and get this error:
× ｢wdm｣: Error: Conflict: Multiple chunks emit assets to the same filename bundle.js (chunks main and vendors-node_modules_css-loader_dist_runtime_api_js-node_modules_react-dom_index_js-node_modu-10bdff)
    at cache.get (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\webpack\lib\Compilation.js:2423:12)
    at AsyncSeriesBailHook.eval [as callAsync] (eval at create (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\tapable\lib\HookCodeFactory.js:32:10), <anonymous>:19:1)
    at Cache.get (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\webpack\lib\Cache.js:27:18)
    at asyncLib.forEach (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\webpack\lib\Compilation.js:2404:18)
    at arrayEach (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\neo-async\async.js:2400:9)
    at Object.each (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\neo-async\async.js:2842:9)
    at asyncLib.forEach (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\webpack\lib\Compilation.js:2394:14)
    at symbolEach (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\neo-async\async.js:2439:9)
    at Object.each (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\neo-async\async.js:2845:16)
    at Compilation.createChunkAssets (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\webpack\lib\Compilation.js:2366:12)
    at hooks.optimizeTree.callAsync.err (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\webpack\lib\Compilation.js:1320:10)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\tapable\lib\HookCodeFactory.js:32:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\tapable\lib\Hook.js:154:20)
    at Compilation.seal (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\webpack\lib\Compilation.js:1235:27)
    at hooks.make.callAsync.err (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\webpack\lib\Compiler.js:574:17)
    at _done (eval at create (C:\Users\artemir\Documents\Projects\@zero-scripts\node_modules\tapable\lib\HookCodeFactory.js:32:10), <anonymous>:9:1)

My configuration, getted by JSON.stringify
And i use Express-like server + webpack-hot-middleware + webpack-dev-middleware

Hi, guys, everything is working fine for me so far, I'm just getting a  DeprecationWarning caused by HotModuleReplacementPlugin  just to let you guys know
(node:18693) DeprecationWarning: [hash] is now [fullhash] (also consider using [chunkhash] or [contenthash], see documentation for details)
<EMAIL_ADDRESS>+<EMAIL_ADDRESS>

Now when you can't use entry name in the cacheGroup's test how do i put a module with all dependencies in the specific cacheGroup?

@artemirq Looks like you specified a constant name for output.filename while a dynamic string like [name].js is needed.
@victors1681 #8553
@MhMadHamster yes, seems like there isn't an easy way to do that now. Why do you need that?

@niieani #8554

@sokra well... long story short: i have a project where i cant use automatically generated bundles, so i'm manually, using optimize.splitChunks, assigning what module should belong to which cacheGroup, currently it's not that bad cause i can just put all of the modules for given cacheGroup in an array and use entry name as a test

https://github.com/webpack/webpack/releases/tag/v5.0.0-alpha.2 with some bugfixes

Docs will be updated along with the v5 release?

@web2033 it is alpha and many things can be changed so documentation is not updated

Awesome work, thanks to all the contributors!
I wanted to raise two things:
1 - namedChunkGroups getting null prototype as key
I can see null prototype objects can't be serialised issue already in the summary so I assume the issue with plugins accessing namedChunkGroups and seeing an object with [Object: null prototype] as the key has already been mentioned.
This issue effects Loadable components server.
2 - Removal of Tapable from Compiler
In webpack 4 Compiler and MultiCompiler extended Tapable, exposing apply. This allowed a consumer to apply a Plugin to the MultiCompiler.
This appears to be removed in webpack 5 which means finding another solution to allow plugins to work over multiple Compilers.
Would it be worth mentioning the removal in the v5 change-log?

Regression: Unable to call toJson without parameters
I think I may have found a small regression.
Previously MultiStats toJson was safe to call with no config, but it appears this refactor removed the check and immediately tries to destructure options.
Scenario
const multiStats = new MultiStats(stats);
multiStats.toJson();

Error
TypeError: Cannot destructure property `children` of 'undefined' or 'null'.

Workaround
const multiStats = new MultiStats(stats);
multiStats.toJson({});

I can see null prototype objects can't be serialised issue already in the summary so I assume the issue with plugins accessing namedChunkGroups and seeing an object with [Object: null prototype] as the key has already been mentioned.

This seem to be something unrelated to serialization. Could you give more details?

In webpack 4 Compiler and MultiCompiler extended Tapable, exposing apply. This allowed a consumer to apply a Plugin to the MultiCompiler.

Plugins have a apply method, all the apply method in Tapable did was calling it. So instead of calling compiler.apply(plugin) you should be able to use plugin.apply(compiler).

@jahredhope should be fixed by #8569

Thanks @sokra , I hope you don't mind another question/feedback:
stats.toJson() 'asset' changes
It appears that the format from toJson stats has changed in a couple of places when referring to assets, was this intentional and is it in the changelog?
I'm noticing when adding support for v5 I will have to do something like:
const assetName = asset.name ? asset.name : asset;

To reproduce
Scenario
const compiler = webpack({});

compiler.run((err, res) => {
  const stats = res.toJson();
  console.log("stats.assetsByChunkName", stats.assetsByChunkName);
}

Result v5
{ main:
   { name: 'main.js',
     size: 220,
     chunks: [ 404 ],
     chunkNames: [ 'main' ],
     emitted: true,
     isOverSizeLimit: false } }

Result v4
{ main: 'main.js' }

https://github.com/webpack/webpack/releases/tag/v5.0.0-alpha.3

Automatic Node.js Polyfills Removed

I strongly object to this change. It will create havoc in the ecosystem... The majority of packages on npm are still mainly written for Node.js. The current auto-polyfilling lets users easily use those packages in the browser too without having to bother the package authors or having to manually include polyfills. Webpack is honestly already an annoyance for Node.js package authors and this will just make it worse. Yes, the polyfills are heavy, but the reality without is even worse. I have no intention of bloating my own packages with browser polyfills, so the result is that many users will have to manually include such polyfills and probably blame me, and it will result in a lot more Webpack-related support on my part.

Should include this on check list? https://github.com/webpack/webpack/issues/8408

@sindresorhus

I strongly object to this change. It will create havoc in the ecosystem... The majority of packages on npm are still mainly written for Node.js. The current auto-polyfilling lets users easily use those packages in the browser too without having to bother the package authors or having to manually include polyfills. Webpack is honestly already an annoyance for Node.js package authors and this will just make it worse. Yes, the polyfills are heavy, but the reality without is even worse. I have no intention of bloating my own packages with browser polyfills, so the result is that many users will have to manually include such polyfills and probably blame me, and it will result in a lot more Webpack-related support on my part.

Isn't this just a matter of webpackconfig.resolve.alias + node-libs-browser? ex:
resolve: {
  alias: Object.assign(
    {},
    require('node-libs-browser'),
    {
      // ...existing aliases
      fs: 'mock',
      crypto: 'empty',
      process: false,
    },
  );
}

I tend to agree with @sindresorhus pretty strongly here as well. The dominant ecosystem semantics should always be the defaults, and while Node.js remains the dominant local JS runtime, we should assume Node.js semantics are the ecosystem semantics from which browser builds are made. Any tool that breaks that will just be causing unnecessary pain for users.

@hulkish: node-libs-browser uses null for some aliases, which the webpack 5 alpha schema rejects.

@sindresorhus @errorx666 hmm actually, there is more to consider which node-libs-browser does not cover... such as process, console, Buffer, etc.
Basically, to really see "the migration difference"...you would need to look at what changed.
@sokra maybe this logic (which has been removed from webpack core) - could be moved node-libs-browser/plugin?
then, people could just do plugins: [new (require('node-libs-browser/plugin'))()]?

Updated performance stats for webpack 5.0.0-alpha.3
Incremental builds are still a lot slower (137% - 154% recompilation time of webpack 4)
Typescript recompilation (watch mode) of 1000 components:
webpack 4 - 1.39 s
webpack 5 - 2.2s
Further details can be seen here:
https://travis-ci.org/namics/webpack-config-plugins/jobs/474225103
https://travis-ci.org/namics/webpack-config-plugins/jobs/474225104

based on this https://github.com/webpack/webpack/releases/tag/v5.0.0-alpha.3
can we implement a NetworkCachePlugin much like metro (https://facebook.github.io/metro/docs/en/caching)?

It looks like prefetching from the runtime chunk emits invalid Javascript. I'm working on a PR to fix now.

global is no longer re-mapped to window.

global is no longer remapped to window by buildin/global.js, but I don't see it documented in the Changelog.

we got a bug on global migrating to wp5 https://github.com/entria/entria-fullstack/pull/46#issuecomment-451647816
@MLoughry is this related to your comment above?

global is no longer remapped to window by buildin/global.js, but I don't see it documented in the Changelog.

Apparently they removed buildins and added runtime plugins, which theorically adds the same functionality, but it is not working properly anymore. When using babel-polyfill for example, we are getting:
Uncaught ReferenceError: global is not defined
    at eval (index.js?e792:25)
    at<EMAIL_ADDRESS>(bundle.js:3822)
    at __webpack_require__ (bundle.js:24)
    at fn (bundle.js:4146)
    at eval (index.tsx:2)
    at Module../src/index.tsx (bundle.js:3951)
    at __webpack_require__ (bundle.js:24)
    at startup (bundle.js:46)
    at bundle.js:53
    at bundle.js:56

Piece of code with problem:
if (global._babelPolyfill && typeof console !== "undefined" && console.warn) {
  console.warn("@babel/polyfill is loaded more than once on this page. This is probably not desirable/intended " + "and may have consequences if different versions of the polyfills are applied sequentially. " + "If you do need to load the polyfill more than once, use @babel/polyfill/noConflict " + "instead to bypass the warning.");
}

I think that the amount of duplicates is by the amount of entries, not sure tho.

Yeah I think so too. Bug

Hello!
If I use
() => import('ui/pages/root')

with src as root for my source code, webpack will create a file with name src_ui_pages_root_index_tsx.js. It is great. But, I  can not see this chunk in assetsByChunkName in stat. As I thought, assetsByChunkName should contain connection between file from build and chunkName? @sokra

But, I can not see this chunk in assetsByChunkName in stat.

() => import('ui/pages/root') is an unnamed chunk. These doesn't appear there. But it's in stats.chunks.

Regarding the node-browser-libs discussion - I'll be very happy when the dependency disappears. It not only makes webpack much bigger than it needs to be, it also gives a false sense of safety - many modules are unmaintained and not in sync with the Node.js code.

+1 for that. I have spent a long time debugging issues caused by incorrect implementations of node APIs in the polyfills (specifically the http/https modules).
I think in the long term its better for libraries to explicitly deal with the issue of using the correct platform APIs if they want to support multiple platforms. It is not possible for webpack to make all platform specific issues disappear, so I think its better to explicitly/completely reject that responsibility.

I was trying to test f446bf8a9b6b718977d24ed402b8a1884d663622 but ran into an issue related to some chunk filenames included in the runtime:
// mapping for filenames not based on template
var staticMapping = {
    "common-root_static_scripts_common_i18n_js": "\"server-common-root_static_scripts_common_i18n_js.js\"",
    // ...
};

The values in this object contain quotes around the file name, so when I try to run the entry point I get MODULE_NOT_FOUND errors like this Error: Cannot find module './"server-common-root_static_scripts_common_i18n_js.js"'.
If I remove the JSON.stringify call at https://github.com/webpack/webpack/blob/f446bf8/lib/runtime/GetChunkFilenameRuntimeModule.js#L69 it works, though I don't know if I'm breaking something else by doing that.
Here's the relevant excerpt from the config I'm using:
  optimization: {
    splitChunks: {
      cacheGroups: {
        common: {
          chunks: 'all',
          filename: 'server-[name].js',
          minChunks: 2,
          minSize: 1,
          maxSize: 102400,
          reuseExistingChunk: true,
        },
        default: false,
        vendors: false,
      },
    },
  },

  output: {
    filename: 'server-[name].js',
    libraryTarget: 'commonjs2',
    path: dirs.BUILD,
    publicPath: PUBLIC_PATH,
  },

  target: 'node',

Hello everyone.
I am trying to use Webpack 5 already 2-hour, but still no success.
Here error:
TypeError: comp.apply is not a function
    at plugins (/Users/dalisoft/Desktop/New Projects/test-work/node_modules/webpack-dev-server/lib/plugins.js:23:10)
    at new DevServer (/Users/dalisoft/Desktop/New Projects/test-work/node_modules/webpack-dev-server/lib/DevServer.js:61:5)
    at start (/Users/dalisoft/Desktop/New Projects/test-work/node_modules/webpack-dev-server/lib/cli/start.js:95:14)
    at options.then (/Users/dalisoft/Desktop/New Projects/test-work/node_modules/webpack-dev-server/cli.js:31:3)
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
    at startup (internal/bootstrap/node.js:282:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:743:3)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `rm -rf dist/** && NODE_ENV=development webpack-dev-server`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      /Users/dalisoft/.npm/_logs/2019-02-23T17_39_09_495Z-debug.log

Dependecies
{
"@swc/core": "^1.0.25",
    "css-loader": "^2.1.0",
    "eslint": "^5.14.1",
    "eslint-config-airbnb": "^17.1.0",
    "eslint-plugin-import": "^2.16.0",
    "eslint-plugin-jsx-a11y": "^6.2.1",
    "eslint-plugin-react": "^7.12.4",
    "friendly-errors-webpack-plugin": "^1.7.0",
    "import-local": "^2.0.0",
    "optimize-css-assets-webpack-plugin": "^5.0.1",
    "sass-loader": "^7.1.0",
    "style-loader": "^0.23.1",
    "swc-loader": "^0.1.4",
    "webpack": "^5.0.0-alpha.11",
    "webpack-cli": "^4.0.0-alpha-4",
    "webpack-dev-server": "^3.0.0-alpha6"
}

Webpack config:
const path = require('path');
const webpack = require('webpack');

const FriendlyErrorsWebpackPlugin = require('friendly-errors-webpack-plugin');

const { NODE_ENV, PORT = 8080 } = process.env;
const isDevelopment = NODE_ENV === 'development';

module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'bundle[name].js',
    path: path.resolve(__dirname, 'dist'),
  },
  resolve: {
    modules: ['src', 'node_modules']
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /(node_modules)/,
        use: {
          loader: 'swc-loader',
          options: {
            jsc: {
              parser: {
                syntax: 'ecmascript',
                jsx: true,
              },
              transform: {
                react: {
                  pragma: 'React.createElement',
                  pragmaFrag: 'React.Fragment',
                  throwIfNamespace: true,
                  development: isDevelopment,
                  useBuiltins: true
                }
              }
            }
          }
        }
      },
      {
        test: /\.module.scss$/,
        exclude: /(node_modules)/,
        use: ['sass-loader', 'style-loader', {
          loader: 'css-loader',
          options: {
            importLoaders: 2
          }
        }]
      },
      {
        test: /\.module.css$/,
        exclude: /(node_modules)/,
        use: ['style-loader', {
          loader: 'css-loader',
          options: {
            importLoaders: 2
          }
        }]
      },
      {
        test: /\.scss$/,
        exclude: /(node_modules)|\.module.scss/,
        use: ['sass-loader', 'style-loader', 'css-loader']
      },
      {
        test: /\.css$/,
        exclude: /(node_modules)|\.module.css/,
        use: ['style-loader', 'css-loader']
      }
    ]
  },
  plugins: [
    new FriendlyErrorsWebpackPlugin(),
		new webpack.HotModuleReplacementPlugin()
  ],
  devServer: {
    contentBase: path.resolve(__dirname, 'dist'),
    host: '<IP_ADDRESS>',
    port: PORT,
    disableHostCheck: true,
    historyApiFallback: true,
    hot: true,
    compress: true
  }
};

{
    "start": "rm -rf dist/** && NODE_ENV=development webpack-dev-server",
    "build": "rm -rf dist/** && NODE_ENV=production npx webpack -p"
  }

Can someone help me?

66666666666666666666666666666666 webpack用着挺好啊 干嘛更新

66666666666666666666666666666666 webpack4用着挺好啊干嘛更新

请只说英文在这里！Single and final warning!
~肖恩

@sokra regarding https://github.com/webpack/webpack/issues/8537#issuecomment-449845441 and https://github.com/webpack/webpack/issues/8537#issuecomment-449873050.

@MhMadHamster yes, seems like there isn't an easy way to do that now. Why do you need that?

I think that this functionality is very valuable and we do not want to lose it in webpack 5.

Using<EMAIL_ADDRESS>it seems the DLL plugin isn't working anymore. Specifically just a simple pointer to a plugin:
new webpack.DllReferencePlugin({
	manifest: path.resolve('manifest.json'),
})

Results in the following build error:
/my-project/node_modules/webpack/lib/Compilation.js:517
		const identifier = module.identifier();
		                          ^

TypeError: module.identifier is not a function
    at Compilation.addModule (/my-project/node_modules/webpack/lib/Compilation.js:517:29)
    at moduleFactory.create (/my-project/node_modules/webpack/lib/Compilation.js:990:35)
    at DllModuleFactory.create (/my-project/packages/aurora-web/node_modules/webpack/lib/DllModuleFactory.js:27:3)
    at semaphore.acquire (/my-project/node_modules/webpack/lib/Compilation.js:968:18)
    at Semaphore.acquire (/my-project/node_modules/webpack/lib/util/Semaphore.js:29:4)
    at Compilation._addModuleChain (/my-project/node_modules/webpack/lib/Compilation.js:967:18)
    at Compilation.addEntry (/my-project/node_modules/webpack/lib/Compilation.js:1074:8)
    at compiler.hooks.make.tapAsync (/my-project/packages/aurora-web/node_modules/webpack/lib/DllEntryPlugin.js:35:16)
    at AsyncParallelHook.eval [as callAsync] (eval at create (/my-project/node_modules/tapable/lib/HookCodeFactory.js:32:10), <anonymous>:7:1)
    at AsyncParallelHook.lazyCompileHook (/my-project/node_modules/tapable/lib/Hook.js:154:20)

@EvHaus Could you create a reproduced repo?

Nevermind @hiroppy. My issue was caused by the fact that I was using webpack@4 as my CLI. After upgrading both the CLI and webpack itself to v5, the issue is gone.

I'm getting the error module is not defined on the built version of this code https://github.com/erikras/redux-form/blob/f209539ea65e1b46534e701c635df31c100c3259/src/util/isHotReloading.js#L3
the resulting code is var castModule = module; and I wonder if it should instead be var castModule = undefined?

Watch mode doesn't seem to be working. I run a React SSR server with start-server-webpack-plugin and watch mode, and it doesn't pick up changes in files.
In the server I also start webpack-dev-server and webpack-hot-middleware to do a client build, and that one doesn't see changes either.

Please help plugin developers to prepare for 5 by deprecating breaking apis e.g: https://github.com/webpack/webpack/issues/8982

Compilation.rebuildModule seems to be broken in the alpha. Digging through the code, it is relying on the removed Module.removeReason inside Compilation.removeReasonsOfDependencyBlock. I imagine this will affect almost all plugins calling rebuild.

@wmertens watcher chokidar was removed in https://github.com/webpack/watchpack/pull/90 for the sake of removing dependencies. IMHO fsevents (that chokidar uses) is the only reliable method to watch files on macos. So if this ships with webpack 5, I forsee a lot of frusttration with mac users. I hope @sokra may at least allow us to use chokidar if installed manually, so mac users may stil use it while webpack by itself has a leaner dependency graph by default.

@sod next version of chokidar remove fsevents too becaue it is unnecessary and many bug fixed in node? What is problem you have without chokidar? Can you provide reproducible test repo? chokidar was create to solve problem nodejs implementation in fs.watch, but they fixed many of them for v8

On macos some watchers drove me up the wall - like watchman, node native or gaze. It manifested in sometimes a change just not being recognised, a few seconds delayed, high cpu consumption, watches triggered multiple times or new directories unwatched until restart. Chokidar was just rock solid. Can't remember a single issue in 2 years.
Tested webpack 5 alpha a few weeks ago and indeed the watcher worked flawless for the few minutes i used it (node 10, macos 10.14). But haven't battletested it in day2day usage on a major project yet.

@sod node@10 should works file without chokidar, in future many projects can migrate from chokidar because now we don't need this, it was workaround for problem between os not more. Will be great if you test wepback@5 with large project and give feedback to us. I think you don't have problems, also avoid chokidar increase perf

@evilebottnawi Would you have a source for what's changed in node 10 that would make Chokidar unnecessary?

Hi,
We recently switched our app to webpack 5 hoping that we could easily split our server code that is running on Google Cloud Functions.
However, doing so led to unexpected crash of our functions, apparently at random times. Sometimes the functions crash with an "out of memory" status, and sometimes they just end because of a timeout, as if they were hanging. The same functions work well most of the time, and always work when the code is not split with webpack.
I understand that running in a serverless environment is quite specific, but I’m really trying to understand what could go wrong in this case.
My intuition is that webpack could be leaking some stuff in the global scope, and that the instances of the Cloud Functions accumulate this memory overhead over time when they are re-used?
Thanks in advance for any clarification or observation on the subject.

@jpreynat could you share your webpack config for v4 and v5?
are you using terser ?

Another less important feedback that I wanted to share is that the deterministic option for moduleIds and chunkIds is taking too much time in our case (we have more than 800 modules in the compiled bundle).
I’ve tried letting the build run for more than 5 minutes during the DeterministicModuleIdsPlugin phase and it never ended so I stopped it manually.
Since using the old size option instead leads to a correct build time (~1min) with cache enabled on other plugins, it doesn’t feel like the initial cost could be worth it at this point.

@sibelius Yes, we are using Terser to mangle our code.
I’ll be glad to share the main part of our config, but since it’s quite big and split in many parts, I’ll have to restructure it a bit first.
I’ll post it in the next hour or so.

@sibelius Here is our current configuration for building the Node app using webpack 5:
const config = {
    target: 'node',
    devtool: 'source-map',
    mode: IS_DEV ? 'development' : 'production',
    context: './src',
    entry: {
        index: ['@babel/polyfill', 'isomorphic-fetch', './src/index.js']
    },
    output: {
        path: './dist',
        publicPath: 'http://localhost:5000',
        filename: '[name].js',
        chunkFilename: `chunks/${
            IS_DEV ? 'chunk.[id].js' : 'chunk.[id].[chunkhash:8].js'
        }`,
        libraryTarget: 'commonjs2',
        pathinfo: false
    },
    externals: [
        nodeExternals({
            modulesDir: './node_modules'
        })
    ],
    recordsPath: '.cache/webpack/records-server.log',
    resolve: {
        symlinks: false,
        extensions: ['.js', '.ts', '.tsx']
    },
    optimization: {
        moduleIds: 'size',
        chunkIds: 'size',
        minimize: !IS_DEV,
        minimizer: [
            new TerserPlugin({
                sourceMap: true,
                cache: '.cache/terser',
                parallel: true,
                terserOptions: {
                    safari10: true,
                    mangle: true,
                    compress: false
                }
            })
        ],
        removeAvailableModules: !IS_DEV,
        removeEmptyChunks: !IS_DEV
    },
    module: {
        rules: [
            {
                test: /(\.js|\.tsx?)$/,
                exclude: /(node_modules)/,
                use: {
                    loader: 'babel-loader',
                    options: {
                        envName: 'node',
                        cacheDirectory: '.cache/babel-loader'
                    }
                }
            },
            {
                test: /\.(png|svg|jpe?g|gif|ico)$/,
                use: [
                    {
                        loader: 'file-loader',
                        options: {
                            name: 'images/[hash].[ext]',
                            emitFile: false
                        }
                    },
                    // Optimize loaded images
                    !IS_DEV && {
                        loader: 'image-webpack-loader',
                        options: {
                            mozjpeg: {
                                progressive: true,
                                quality: 65
                            },
                            optipng: {
                                enabled: false
                            },
                            svgo: {
                                enabled: false
                            },
                            pngquant: {
                                enabled: true,
                                quality: '65-90',
                                speed: 10
                            },
                            gifsicle: {
                                interlaced: false
                            }
                        }
                    }
                ].filter(Boolean)
            },
            {
                test: /\.(ttf|eot|otf|woff|woff2)$/,
                use: {
                    loader: 'file-loader',
                    options: {
                        name: 'fonts/[hash].[ext]',
                        emitFile: false
                    }
                }
            },
            {
                test: /\.(css)$/,
                use: [
                    {
                        loader: 'file-loader',
                        options: {
                            name: 'css/[hash].[ext]',
                            emitFile: false
                        }
                    },
                    {
                        loader: 'extract-loader'
                    },
                    {
                        loader: 'css-loader'
                    }
                ]
            }
        ]
    },
    plugins: [
        new webpack.DefinePlugin({
            'process.env.NODE_ENV': JSON.stringify(
                IS_DEV ? 'development' : 'production'
            )
        })
    ]
};

We use the exact same configuration for webpack 4, except that of course the optimization.splitChunks is taken into account with webpack 5.
To split our code, I'm using dynamic imports import('module'), and simply enable it on webpack 5 by removing the babel-plugin-dynamic-import-node module from our babel configuration.

To help illustrate this behavior, here is a stacked bar graph of our functions finishing with an "out of memory" execution status.
We deployed using webpack 5 on April 13th.

Since we redeployed an hour ago with webpack 4, there is no sign of such errors.

@jpreynat Looks we have memory leak, do you find place (plugin/loader/option)?

Hi @evilebottnawi,
It seems so yes. But locating it is quite hard, because we use lots of plugins/presets and loaders.
If I have time by the end of the week, I'll try minimizing our config to make a smaller reproducible example.

@jpreynat feel free to ping me

Sadly, I didn't find the time to investigate the reasons of the memory issue yet.
However, by testing migration from webpack 4 to 5 for client-side code only, I ran into another issue.
We are bundling our code into two entrypoints, that share lots of code.
While lots of initial and async chunks were generated and correctly shared with webpack 4, using the exact same configuration with webpack 5 leads to lots of code being duplicated.
Our optimization config is quite straightforward though:
optimization: {
    splitChunks: {
        chunks: 'all',
        maxSize: 100000,
        automaticNameDelimiter: '-'
    }
},

This issue results in lot of shared code that is duplicated between our two entrypoints, leading to an increase of our total bundled size.
Here is an example of some duplicates (among many) using the optimization.chunkIds: 'named' option, to which I only redacted the actual names:
36K	./public/static/js/[named-1]-fdc8d60.8fd65027.js
36K	./public/static/js/[named-1]-fdc8d61.4999f096.js
36K	./public/static/js/[named-2]-8af4070.9a83add1.js
36K	./public/static/js/[named-2]-8af4071.7b3a9092.js
20K	./public/static/js/[named-3]-3609840.8f02bc36.js
20K	./public/static/js/[named-3]-3609841.5c61c82d.js

After looking quickly, it seems that the shared files bundled with webpack 4 were named chunk.[entry-1]-[entry-2]-[id].[chunkhash], while no files common to both entrypoints are generated with webpack 5.
Any ideas what could go wrong here?
Thanks in advance.

@jpreynat webpack 5 changes two things compared to webpack 4 in the splitChunks stuff:
First, the [entry-1]-[entry-2] naming was removed. It would lead to unneeded cache invalidation, i. e. when [entry-3] now also shares the code. This would change the name to [entry-1]-[entry-2]-[entry-3] while content stays equal. The chunkIds: "named" algorithm should generate more useful names anyway based on the content of the chunk.
Second, minRemainingSize was added which ensures that the chunk that remains after splitting of the common modules has a minimum size. By default it's 30kb. So this will prevent extracting a common part when the non-common part is < 30kb. It was intended to prevent vendor splitting when app code is too small. But I could imagine this being a problem for commons splitting. You can try to set splitChunks.minRemainingSize: 1 to workaround this and verify that this is the problem. I see how to optimize this for scenarios when chunk count >= 2...

Hi @sokra
Thanks for the insights, I better understand the reasons of the changes on chunks names. That totally makes sense.
I've tested setting the minRemainingSize: 1 option at the splitChunks scope and it works like a charm. This reduces our total bundle size from 6.7 to 5.8MB, and the size of the entry points from 3.88 to 3.08MB, which is huge.
Is this something that you can work out directly in webpack without having to hardcode this option?

Is this something that you can work out directly in webpack without having to hardcode this option?

Yep, in progress...

Thanks @sokra for the quick action, highly appreciated!

@jantimon Did you still need help stamping out "html-webpack-plugin misses fileTimestamps (should use fileSystemInfo)"?

@evenstensberg what's status on "webpack-cli misses Stats.presetToOptions (should use compilation.createStatsOptions"

@jpreynat splitChunks issue should be fixed in 5.0.0-alpha.16

@TheLarkInn @jantimon is waiting this https://github.com/webpack/webpack/issues/8982 to fix html-wepback-plugin

Thanks @sokra!

webpack-dev-server fails with 5.0.0-alpha.16
$ webpack-dev-server
internal/modules/cjs/loader.js:626
    throw err;
    ^

Error: Cannot find module 'webpack/lib/node/NodeOutputFileSystem'
Require stack:
- ../node_modules/webpack-dev-middleware/lib/fs.js
- ../node_modules/webpack-dev-middleware/index.js
- ../node_modules/webpack-dev-server/lib/Server.js

@apostolos webpack-dev-middleware is fixed in https://github.com/webpack/webpack-dev-middleware/pull/436.

@apostolos webpack-dev-middleware is fixed in https://github.com/webpack/webpack-dev-middleware/pull/436 now. 🚀

...and, out-of-memory error with webpack-dev-server:
yarn run v1.15.2
$ DEV_SERVER=true webpack-dev-server --hot --config=./script/webpack/app.config.js
Starting type checking service...
Using 1 worker with 2048MB memory limit
ℹ ｢wds｣: Project is running at http://localhost:3808/
ℹ ｢wds｣: webpack output is served from http://localhost:3808/webpack/
ℹ ｢wds｣: Content not from webpack is served from /Users/joshgoldberg/Codecademy-dev/repos/Codecademy
ℹ ｢wdm｣: wait until bundle finished: /webpack/manifest.json
ℹ ｢wdm｣: wait until bundle finished: /webpack/manifest.json

<--- Last few GCs --->

[18670:0x102801000]   237233 ms: Mark-sweep 1305.8 (1510.4) -> 1305.8 (1510.4) MB, 868.1 / 0.0 ms  allocation failure GC in old space requested
[18670:0x102801000]   238323 ms: Mark-sweep 1305.8 (1510.4) -> 1305.8 (1471.9) MB, 1090.1 / 0.0 ms  last resort GC in old space requested
[18670:0x102801000]   239330 ms: Mark-sweep 1305.8 (1471.9) -> 1305.8 (1465.4) MB, 1006.2 / 0.0 ms  last resort GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x63979d257c1 <JSObject>
    1: /* anonymous */ [/Users/joshgoldberg/Codecademy-dev/repos/Codecademy/node_modules/source-map/lib/source-node.js:~342] [pc=0x2641149f357f](this=0x63900a0c211 <JSGlobal Object>,chunk=0x639e5566591 <String[27]: \n  margin-left: 0.3125rem;>,original=0x63959ff3e29 <Object map = 0x6398ee41ef1>)
    2: SourceNode_walk [/Users/joshgoldberg/Codecademy-dev/repos/Codecademy/node_modules/source-map/li...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/Users/joshgoldberg/.nvm/versions/node/v8.10.0/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/Users/joshgoldberg/.nvm/versions/node/v8.10.0/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/Users/joshgoldberg/.nvm/versions/node/v8.10.0/bin/node]
 4: v8::internal::Factory::NewUninitializedFixedArray(int) [/Users/joshgoldberg/.nvm/versions/node/v8.10.0/bin/node]
 5: v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/Users/joshgoldberg/.nvm/versions/node/v8.10.0/bin/node]
 6: v8::internal::Runtime_GrowArrayElements(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/joshgoldberg/.nvm/versions/node/v8.10.0/bin/node]
 7: 0x2641138842fd
 8: 0x2641149f357f
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

The config is available on https://www.npmjs.com/package/@codecademy/webpack-config, though the code I'm running with is unfortunately closed source. It's about 1000 JS files and 300 TS files, plus a roughly 1.7 MB node_modules/ directory.

@JoshuaKGoldberg try to increase memory, looks problem in source maps

@sokra regression in latest release (v5.0.0-alpha.17), inside plugin:
compiler.hooks.afterPlugins.tap(plugin, () => {
        const {
          cache,
          filter,
          test,
          include,
          exclude,
          bail,
          imageminOptions,
          name
        } = this.options;

        compiler.options.module.rules.push({
          enforce: "pre",
          exclude, // undefined by default
          include, // undefined by default
          loader: path.join(__dirname, "imagemin-loader.js"),
          options: {
            bail,
            cache,
            filter,
            imageminOptions,
            name
          },
          test
        });
      });

Output
Compiling RuleSet failed: Expected condition but got falsy value (at ruleSet[1].rules[1].include: undefined)

Before next branch has not this problem.

@sokra We are encountering a major regression in our code between the 5.0.0-alpha.14 version and all subsequent ones.
The code is compiling correctly, but we have an error at runtime.
Basically, we are simply only exporting an object to store our configuration, defined as a constant and exporting it as default.
// config.ts
const config = {
    serviceOne: {
        keyOne: 'value',
        // other keys...
    },
    // other values...
};

export default config;

It is then imported by different parts of our code as import config from '<path-to-config>'.
Starting from<EMAIL_ADDRESS>we encounter an error Cannot read property 'keyOne' of undefined. Given the stack trace, undefined would be the serviceOne key of our config object.
However, exporting and importing the config object as non-default works.
// config.ts
export { config };

// consumer.ts
import { config } from '<path-to-config>';

Do you have any idea what could go wrong here?

@jpreynat just to make sure, the config doesn't import anything else, so it's not an import loop, right?

Hi @wmertens,
No import loop, plus it's working on webpack until the alpha.15.
Our config only do an import * as functions from 'firebase-functions'; because our code is running on Firebase cloud functions.

Adding 2c, but curious if the disk cache doesn't "solve" this ticket too?
https://github.com/webpack/webpack/issues/4991
I think it goes really well with the disk cache work, in that it improves startup time (in our case it should improve it by quite a lot).
Either way, if not using the disk cache, it's useful for us to have a "skipInitialBuild" option, which would avoid in our case about 15s startup time.

@jpreynat Your issue should be fixed by https://github.com/webpack/webpack/pull/9618 through I can't verify it without repro case. Either test it yourself or provide some repo.
@natew With disk cache startup is at least a lot faster now. As rule of thumb you can estimate 1s per MB bundle size (unminimized) plus 1s startup time. Skipping the initial build is not possible, it's needed to figure out which files to watch. If no change happened since last build it basically restores all modules from the disk cache to the memory cache and checks if they are still valid. It currently always rewrites all output files (but it doesn't re-generate them if unchanged), but this is something we could optimize later too.

Thanks for the reply. Yea in our case we are loading a workspace of apps, a
small workspace in this case has 8 apps each with two bundles, plus the
shared DLL and the main bundle. So you have about 18 webpack processes
starting, and right now it takes about 40 seconds on my machine with some
cache setup.
There’s no reason they should need to build again here though, we persist
information on exit that stores a hash of the files and the bundle
information so we know they are up to date.
I suppose in the future there could be further optimizations that prevent a
bit more work on the startup side as well — avoiding the need to write out
the new file if it hasn’t changed, and perhaps even on parsing the files as
well.

avoiding the need to write out the new file if it hasn’t changed

yep, that's on the list.

and perhaps even on parsing the files as well

when Persistent Cache hits no file is parsed at all

@jpreynat Please try v5.0.0-alpha.21, and check if this fixes your issue.

@sokra This is working indeed 🎉
Thanks a lot for the fix.

@jpreynat How is your experience with webpack 5 so far?

npm run dev   webpack-dev-server
Error Log
node_modules\webpack-cli\bin\utils\convert-argv.js:141
                        if (webpackConfigurationValidationErrors.length) {
                                            ^
TypeError: Cannot read property 'length' of undefined
    at processConfiguredOptions (D:\DevelopmentProject\Webpack5Test\node_modules\webpack-cli\bin\utils\convert-argv.js:141:45)
    at module.exports (D:\DevelopmentProject\Webpack5Test\node_modules\webpack-cli\bin\utils\convert-argv.js:133:10)
    at Object.<anonymous> (D:\DevelopmentProject\Webpack5Test\node_modules\webpack-dev-server\bin\webpack-dev-server.js:84:40)
    at Module._compile (internal/modules/cjs/loader.js:774:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:785:10)
    at Module.load (internal/modules/cjs/loader.js:641:32)
    at Function.Module._load (internal/modules/cjs/loader.js:556:12)
    at Function.Module.runMain (internal/modules/cjs/loader.js:837:10)
    at internal/main/run_main_module.js:17:11

webpack-cli is not compatibility with webpack@5 right now :disappointed:

I’ll submit a fix later today

@sokra Good actually. We've been using it for our production app for a few months now, and everything is running smoothly.
I'm eager to test the disk caching, but I don't know how stable it is yet. The last time I checked, there were risks as it wasn't guaranteed to be cleared when dependencies were updated.
Otherwise, it is pretty stable on our side.

@jpreynat Does mini-css-extract-plugin is incompatible work for you? That's the one thing currently holding us back.

@phaistonian Sorry, but we are not using it, so I couldn't say how it goes with webpack 5.

@zackify This seem to be cause by some incompatible/outdated plugin or loader, which uses an old approach to inherit the cache for child compilers.
It try to make compilation.cache non-write-able to make it easier to find problems like that.

Looks bug in cache-loader

@zackify can you create minimum reproducible test repo?

The Dotenv plugin doesn't seem to be working, I am getting:
Uncaught ReferenceError: process is not defined

In the browser. I have added Dotenv like this to my webpack config:
const compiler = webpack({
  ...
  plugins: [
    new Dotenv()
  ]
})

const watching = compiler.watch({...}, fn)

Any ideas?

@lancepollard There was no change to the DefinePlugin, so Dotenv should work fine. But there was a change to process itself. The polyfill was removed in webpack 5, so process.env.SOMETHING should work but only process would fail.
What's in the line where the error is coming from?

@zackify Seem related to validating build dependencies of the pack. The error is probably a bit confusing because it lists all the entries. I'll improve the error for such scenario.
You can get more info and a stack trace with this config infrastructureLogging: { debug: /PackFileCacheStrategy/ }

@sokra thanks, I did that, and it looked like an eslint loader error, then css loader. Both were out of date. After updating those, I'm still stuck on this, and I am using the latest babel-loader (8.0.6). Still trying to debug it more myself. Appreciate all the help!
<w> [webpack.cache.PackFileCacheStrategy] Restoring failed for /module//Users/zsilveira/projects/web-ccp/node_modules/babel-loader/lib/index.js??ruleSet[1].rules[2].oneOf[2]!/Users/zsilveira/projects/web-ccp/node_modules/react-dev-utils/webpackHotDevClient.js from pack: TypeError: Cannot destructure property `startTime` of 'undefined' or 'null'.
    [webpack.cache.PackFileCacheStrategy] TypeError: Cannot destructure property `startTime` of 'undefined' or 'null'.
        at FileSystemInfo.checkSnapshotValid (/Users/zsilveira/projects/web-ccp/node_modules/webpack/lib/FileSystemInfo.js:796:7)
        at Promise.all.Promise (/Users/zsilveira/projects/web-ccp/node_modules/webpack/lib/cache/PackFileCacheStrategy.js:313:27)
        at new Promise (<anonymous>)
        at fileSerializer.deserialize.catch.then.packContainer (/Users/zsilveira/projects/web-ccp/node_modules/webpack/lib/cache/PackFileCacheStrategy.js:312:6)

Interesting, I was able to get it to continue by changing: 	checkSnapshotValid(snapshot = {}, callback) { in the FileSystemInfo file, adding a default as an object for snapshot. But then it gets stuck starting with no other output when i have verbose stats on.

I find removing node polyfills can introduce many many issues on webpack build.
Using stream module as an example, we can install stream-browserify aside with an alias configuration to make require('stream') work in browser - just what we expected.
The fact is stream-browserify requires core-util-is which requires a global Buffer variable.
After fixing this by manually modify its implement, we encountered an new problem that readable-stream requires a global process variable.
Still after fixing this, a third issue comes with browserify-sign requries Buffer global variable
The root cause of all these is that previous NodeSourcePlugin can walk through source code and replace global variable like process and Buffer to corresponding require statements, however polyfill packages and alias configuration only works with an explicit require or import declaration, all these fails when any package access node modules via globals.
I'd like to recommend even with the default behavior of removing polyfills from webpack v5, it should ship with an older version of NodeSourcePlugin to allow developers catch back node global variables with ease, currently shipped NodeSourcePlugin only works for {global: true}.

@otakustay why not remove stream from your build?

@otakustay why not remove stream from your build?

In projects like pdfkit, removing 'stream' dependency would mean a complete rewrite of the public interface, so this is out of question.
A solution like a opt in plugin is more than desirable

@otakustay why not remove stream from your build?

By simply importing uuid package, it requires crypto and then stream, vm, process are all required implicitly, it is not a choice that we can get rid of these.

Currently I introduce babel-plugin-import-globals to replace global node modules into imports:
{
    test: /\/.js[x]$/,
    include: /node_modules/,
    use: [
        {
            loader: 'babel-loader',
            options: {
                sourceType: 'unambiguous',
                plugins: [
                    [
                        'babel-plugin-import-globals',
                        {
                            'process': 'process',
                            'Buffer': {moduleName: 'buffer', exportName: 'Buffer'},
                        }
                    ],
                ],
            },
        },
    ],
}

This seems to slow down build speed, but I'm wondering how it would compare to previous NodeSourcePlugin

@blikblum @otakustay I am struggling to understand why you would ship modules that were not meant for browser use to browsers. For uuid, simply use https://www.npmjs.com/package/uuid-browser, and for pdfkit they have a section explaining how to use it in the browser, so I'm sure they would like to know it will break with webpack 5.

Most of the time it is not us to import those node only modules, we just encounter an indirect dependency and have to fix that.

exactly - so that's when you replace uuid with uuid-browser, thereby fixing it.

uuid is still not a direct dependency to me, I can have tens of such packages introducing unwanted node global variable access, the entire dependency graph can be very complex in real world, as a developer I'm not really willing to address all sorts of dependency issues.

but as a developer you should also make good applications for your end users, and shipping lots of extra code that they have to download on their crappy 3G is not good for them. In general, bundling node libraries is entirely avoidable, and just polyfilling them away doesn't feel right to me.
I understand that you want a way to say "I don't give a 💩 about application sizes, just make it work", and then indeed you'd need some webpack plugin that does the polyfilling that was there before. I also understand that the webpack team doesn't want to encourage bloated bundles.

The change was intentionally made to bring up these node core modules as issues. Yes, this may break some packages, but keep in mind our long term goal is to move frontend development towards native browser behavior not towards native node.js behavior.
Package developers have multiple options to "fix" their packages:
They could avoid using node.js core modules at all.
They could avoid using node.js core modules only for frontend usage (and keep using node.js core modules for in node.js usage). The "browser" field in package.json can be used to switch internals for fontend usage.
They could offer node.js core module polyfills directly. The "browser" field can i. e. map "stream": "stream-browserify". These modules need to be added as dependencies to the package.
They could do nothing and force the application developer to choose polyfills theirselve.
Application developers can add node.js core module polyfills via resolve.alias, i. e. alias: { stream: "stream-browserify" }, and polyfills for global variables like Buffer and process via new ProvidePlugin({ Buffer: "buffer", process: "process-browserify" }). These polyfills need to be added as dependencies to the application.
Note that you can also apply a resolve configuration only to a part of your application via module.rules[].resolve. This might be nice to "see" which modules need these polyfills. Both resolve.alias and ProvidePlugin only attach polyfills dependencies to modules using node.js core modules. This also means polyfills are subject to Code Splitting when only used in modules behind import().
Feel free to publish and maintain a node-polyfill-webpack-plugin which add all polyfills by default. I don't intend to do so, as it might encourage people to keep using these stuff. My idea was to make it annoying so in long term offending packages get improved.

@sokra After updating to the latest version, I'm now experiencing issues because there are incompatibilities between webpack 5, webpack-dev-server and webpack-cli.
Any plans to update those so the modules can work smoothly altogether?
FYI, here is the error when working with<EMAIL_ADDRESS>			if (webpackConfigurationValidationErrors.length) {
			                                         ^
TypeError: Cannot read property 'length' of undefined
    at processConfiguredOptions (/Users/jpreynat/GitBook/gitbook-new-duplicate/node_modules/webpack-cli/bin/utils/convert-argv.js:141:45)
    at module.exports (/Users/jpreynat/GitBook/gitbook-new-duplicate/node_modules/webpack-cli/bin/utils/convert-argv.js:133:10)
    at Object.<anonymous> (/Users/jpreynat/GitBook/gitbook-new-duplicate/node_modules/webpack-dev-server/bin/webpack-dev-server.js:84:40)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)
    at Function.Module.runMain (module.js:694:10)
    at startup (bootstrap_node.js:204:16)
    at bootstrap_node.js:625:3

And with<EMAIL_ADDRESS>module.js:550
    throw err;
    ^

Error: Cannot find module 'webpack-cli/bin/config-yargs'
    at Function.Module._resolveFilename (module.js:548:15)
    at Function.Module._load (module.js:475:25)
    at Module.require (module.js:597:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/Users/jpreynat/GitBook/gitbook-new-duplicate/node_modules/webpack-dev-server/bin/webpack-dev-server.js:65:1)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)

The change was intentionally made to bring up these node core modules as issues

I totally understand this decision is a good one to push forward web friendly package ecosystem, and definitely on webpack's side.
What is currently embarrassing is that stream-browserify itself is not web compatible since it introduces dependencies accessing process and Buffer globally.
I'd like to recommend webpack to warn developers on global node variables access, not only those using import or require statements, this can help use migrate to v5 more efficiently.

@jpreynat what problem with webpack-dev-server? Should work fine with webpack@5

I'd like to recommend webpack to warn developers on global node variables access, not only those using import or require statements, this can help use migrate to v5 more efficiently.

:+1: yep we can add that

@sokra Thanks for answering quickly.
I've got the two errors that I pointed out here.
You can see that both of them occur in webpack-dev-server, while trying to access stuff in webpack-cli.

@jpreynat i can't understand what is broken in webpack-dev-serverm please clarify (it can be broken only if you use webpack-dev-server bun due webpack-cli)

@jpreynat I believe webpack-cli is the only thing broken, webpack-dev-server works as expected if you invoke it programatically.

Simply running the $ ./node_modules/.bin/webpack-dev-server command is launching the process, but as soon as I pass it our actual config file with $ ./node_modules/.bin/webpack-dev-server --config <path-to-config>.js, it is failing with the following error:
/node_modules/webpack-cli/bin/utils/convert-argv.js:140
		if (webpackConfigurationValidationErrors.length) {
		                                         ^

TypeError: Cannot read property 'length' of undefined
    at processConfiguredOptions (/node_modules/webpack-cli/bin/utils/convert-argv.js:140:44)
    at module.exports (/node_modules/webpack-cli/bin/utils/convert-argv.js:131:10)
    at Object.<anonymous> (/node_modules/webpack-dev-server/bin/webpack-dev-server.js:84:40)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)
    at Function.Module.runMain (module.js:694:10)
    at startup (bootstrap_node.js:204:16)

Here are the logs when running<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

@jpreynat can you open issue in webpack-dev-server? I think we should output warning about cli for webpack@5

Fixing in a few hours

It seems webpack 5 has extraordinary memory usage on my config
<--- Last few GCs --->

[16857:0x103d83000]   109998 ms: Mark-sweep 1926.2 (2082.8) -> 1894.8 (2070.6) MB, 745.1 / 0.0 ms  (average mu = 0.136, current mu = 0.084) allocation failure scavenge might not succeed
[16857:0x103d83000]   110998 ms: Mark-sweep 1905.7 (2070.6) -> 1899.1 (2069.1) MB, 975.3 / 0.0 ms  (average mu = 0.078, current mu = 0.025) allocation failure scavenge might not succeed

<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x1c5004040911 <JSObject>
    0: builtin exit frame: defineProperty(this=0x1c50040409a9 <JSFunction Object (sfi = 0x1c5014a07b49)>,0x1c50568690c1 <Object map = 0x1c5077bbb0f9>,0x1c502781f9c1 <String[#15]: currentFileInfo>,0x1c5056869039 <Dimension map = 0x1c5039561749>,0x1c50040409a9 <JSFunction Object (sfi = 0x1c5014a07b49)>)

    1: dimension [0x1c50b0242f31] [/Users/otakustay/Develop/baidu/intelligent-dev/frontend/nod...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x100078b00 node::Abort() [/usr/local/Cellar/node/12.6.0/bin/node]
 2: 0x100078c38 node::OnFatalError(char const*, char const*) [/usr/local/Cellar/node/12.6.0/bin/node]
 3: 0x10016ad65 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node/12.6.0/bin/node]
 4: 0x10016ad07 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/Cellar/node/12.6.0/bin/node]
 5: 0x1002c3471 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/Cellar/node/12.6.0/bin/node]
 6: 0x1002c4318 v8::internal::Heap::HasLowYoungGenerationAllocationRate() [/usr/local/Cellar/node/12.6.0/bin/node]
 7: 0x1002c2619 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/Cellar/node/12.6.0/bin/node]
 8: 0x1002c0f81 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/Cellar/node/12.6.0/bin/node]
 9: 0x1002c813a v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/usr/local/Cellar/node/12.6.0/bin/node]
10: 0x1002c8184 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/usr/local/Cellar/node/12.6.0/bin/node]
11: 0x1002a78e0 v8::internal::Factory::AllocateRawArray(int, v8::internal::AllocationType) [/usr/local/Cellar/node/12.6.0/bin/node]
12: 0x1002a73cc v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::RootIndex, int, v8::internal::Object, v8::internal::AllocationType) [/usr/local/Cellar/node/12.6.0/bin/node]
13: 0x100392e59 v8::internal::HashTable<v8::internal::NameDictionary, v8::internal::NameDictionaryShape>::New(v8::internal::Isolate*, int, v8::internal::AllocationType, v8::internal::MinimumCapacity) [/usr/local/Cellar/node/12.6.0/bin/node]
14: 0x100392dd3 v8::internal::BaseNameDictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape>::New(v8::internal::Isolate*, int, v8::internal::AllocationType, v8::internal::MinimumCapacity) [/usr/local/Cellar/node/12.6.0/bin/node]
15: 0x1003e03a3 v8::internal::JSObject::MigrateToMap(v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Map>, int) [/usr/local/Cellar/node/12.6.0/bin/node]
16: 0x100383a21 v8::internal::LookupIterator::TransitionToAccessorProperty(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes) [/usr/local/Cellar/node/12.6.0/bin/node]
17: 0x1003da403 v8::internal::JSObject::DefineAccessor(v8::internal::LookupIterator*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyAttributes) [/usr/local/Cellar/node/12.6.0/bin/node]
18: 0x1003d9fd2 v8::internal::JSReceiver::ValidateAndApplyPropertyDescriptor(v8::internal::Isolate*, v8::internal::LookupIterator*, bool, v8::internal::PropertyDescriptor*, v8::internal::PropertyDescriptor*, v8::Maybe<v8::internal::ShouldThrow>, v8::internal::Handle<v8::internal::Name>) [/usr/local/Cellar/node/12.6.0/bin/node]
19: 0x1003d945e v8::internal::JSReceiver::OrdinaryDefineOwnProperty(v8::internal::LookupIterator*, v8::internal::PropertyDescriptor*, v8::Maybe<v8::internal::ShouldThrow>) [/usr/local/Cellar/node/12.6.0/bin/node]
20: 0x1003d914e v8::internal::JSReceiver::OrdinaryDefineOwnProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::JSObject>, v8::internal::Handle<v8::internal::Object>, v8::internal::PropertyDescriptor*, v8::Maybe<v8::internal::ShouldThrow>) [/usr/local/Cellar/node/12.6.0/bin/node]
21: 0x1003d8d4f v8::internal::JSReceiver::DefineProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [/usr/local/Cellar/node/12.6.0/bin/node]
22: 0x1001fe7a4 v8::internal::Builtin_Impl_ObjectDefineProperty(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/usr/local/Cellar/node/12.6.0/bin/node]
23: 0x10071ac19 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/usr/local/Cellar/node/12.6.0/bin/node]
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

In maximum it can consume 2.5GB memory to build my app.
This happens when I use css-loader and style-loader to handle css files, replacing css-loader with raw-loader can complete the build successfully but still consume 900MB memory

@evilebottnawi
Issue opened here.

@otakustay can you create issue in css-loader with reproducible test repo?

@zackify I tried to fix the issues you mentioned above (https://github.com/webpack/webpack/issues/8537#issuecomment-526256531) in 5.0.0-alpha.24.
It also comes with major Tree Shaking improvements (which probably lead to more bugs, but let's hope it works fine).

@sokra
Just tested the 5.0.0-alpha.24 for its promising tree-shaking improvements, and I run into an error without any changes to our config.
./node_modules/webpack/lib/RuntimeTemplate.js:497
			throw new Error(
			^

Error: RuntimeTemplate.importStatment(): Module ./modules/node_modules/libphonenumber-js/es6/parsePhoneNumberFromString.js has no id. This should not happen.
    at RuntimeTemplate.importStatement (./node_modules/webpack/lib/RuntimeTemplate.js:497:10)
    at HarmonyImportSpecifierDependency.getImportStatement (./node_modules/webpack/lib/dependencies/HarmonyImportDependency.js:80:26)
    at HarmonyImportSpecifierDependencyTemplate.apply (./node_modules/webpack/lib/dependencies/HarmonyImportDependency.js:226:9)
    at HarmonyImportSpecifierDependencyTemplate.apply (./node_modules/webpack/lib/dependencies/HarmonyImportSpecifierDependency.js:220:9)
    at HarmonyImportSpecifierDependencyConcatenatedTemplate.apply (./node_modules/webpack/lib/optimize/ConcatenatedModule.js:1366:26)
    at JavascriptGenerator.sourceDependency (./node_modules/webpack/lib/JavascriptGenerator.js:191:12)
    at JavascriptGenerator.sourceBlock (./node_modules/webpack/lib/JavascriptGenerator.js:143:9)
    at JavascriptGenerator.generate (./node_modules/webpack/lib/JavascriptGenerator.js:88:8)
    at NormalModule._generateSource (./node_modules/webpack/lib/NormalModule.js:711:21)
    at NormalModule.getRuntimeRequirements (./node_modules/webpack/lib/NormalModule.js:777:15)
    at ConcatenatedModule.getRuntimeRequirements (./node_modules/webpack/lib/optimize/ConcatenatedModule.js:1306:30)
    at Compilation.processRuntimeRequirements (./node_modules/webpack/lib/Compilation.js:1508:40)
    at hooks.optimizeTree.callAsync.err (./node_modules/webpack/lib/Compilation.js:1382:9)
    at Hook.eval [as callAsync] (eval at create (./node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (./node_modules/webpack/node_modules/tapable/lib/Hook.js:18:14)
    at Compilation.seal (./node_modules/webpack/lib/Compilation.js:1340:27)
    at compilation.finish.err (./node_modules/webpack/lib/Compiler.js:739:19)
    at hooks.finishModules.callAsync.err (./node_modules/webpack/lib/Compilation.js:1265:4)
    at _next1 (eval at create (./node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:16:1)
    at _err1 (eval at create (./node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:33:1)
    at ./node_modules/neo-async/async.js:2830:7
    at Object.each (./node_modules/neo-async/async.js:2850:39)

It happens in the libphonenumber-js module.
If this can be of any help, here is the content of the file that makes it fail es6/parsePhoneNumberFromString.js:
import { normalizeArguments } from './parsePhoneNumber';
import parsePhoneNumberFromString_ from './parsePhoneNumberFromString_';

export default function parsePhoneNumberFromString() {
	var _normalizeArguments = normalizeArguments(arguments),
	    text = _normalizeArguments.text,
	    options = _normalizeArguments.options,
	    metadata = _normalizeArguments.metadata;

	return parsePhoneNumberFromString_(text, options, metadata);
}
//# sourceMappingURL=parsePhoneNumberFromString.js.map

@evilebottnawi I've located that memory consumption issue is introduced by less-loader, by simply import 300 less files with 50 lines, it can cost 1.3-1.5GB memory. Maybe I should raise an issue to less-loader?

@otakustay you are on webpack@5?

Both webpack@4 and webpack@5 consumes the same memory, one of my app's build runs out of memory accidentally after I upgraded to 5.x, so I incorrectly think it should be the webpack@5's issue.

@otakustay open issue in less-loader with reproducible test repo

Thanks for your continuous testing and problem reporting. This is very important and beneficial for me.
@jpreynat Here is the bugfix: https://github.com/webpack/webpack/pull/9666

@jpreynat https://github.com/webpack/webpack/releases/tag/v5.0.0-alpha.25

@sokra getting the following error when I add additional files to cache.buildDependencies.config[]:
TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be one of type string, Buffer, TypedArray, or DataView. Received type undefined
    at Hash.update (internal/crypto/hash.js:69:11)
    at BulkUpdateDecorator.update (./node_modules/webpack/lib/util/createHash.js:49:14)
    at ./node_modules/webpack/lib/FileSystemInfo.js:1247:39
    at ./node_modules/neo-async/async.js:2830:7
    at done (./node_modules/neo-async/async.js:2925:13)
    at ./node_modules/webpack/lib/FileSystemInfo.js:1222:27
    at ./node_modules/webpack/lib/util/AsyncQueue.js:267:5
    at processTicksAndRejections (internal/process/task_queues.js:75:11)

I think this started happening since alpha.24.
My config looks like this:
const config = {
  cache: {
      type: 'filesystem',
      buildDependencies: {
        config: [__filename, path.resolve(__dirname, 'node_modules/.yarn-integrity')],
        // config: [__filename], // works fine
      },
    },
  ...rest
}

@sokra one more problem. I've tried alpha.25 in many projects without issues, except when emotion is being used.
Production compilation crashes with the following error (dev mode works fine):
ERROR in {179} [entry] [initial] main.009d35ef3a418731ba47.js
<EMAIL_ADDRESS>Unexpected token (46:54)
| };
|
| if (false) /* unused pure expression */ undefined && ()/* unused pure expression */ undefined && ()/* unused pure expression */ undefined && ()/* unused pure expression */ undefined && (){ var hyphenatedCache, hyphenPattern, msPattern, oldProcessStyleValue, contentValues, contentValuePattern; }
|
| var shouldWarnAboutInterpolatingClassNameFromCss = /* unused pure expression */ undefined && (true); SyntaxError<EMAIL_ADDRESS>Unexpected token (46:54)
| };
|
| if (false) /* unused pure expression */ undefined && ()/* unused pure expression */ undefined && ()/* unused pure expression */ undefined && ()/* unused pure expression */ undefined && (){ var hyphenatedCache, hyphenPattern, msPattern, oldProcessStyleValue, contentValues, contentValuePattern; }
|
| var shouldWarnAboutInterpolatingClassNameFromCss = /* unused pure expression */ undefined && (true);
    at NewParser.pp$4.raise (./node_modules/acorn/dist/acorn.js:2836:15)
    at NewParser.pp.unexpected (./node_modules/acorn/dist/acorn.js:689:10)
    at NewParser.pp$3.parseParenAndDistinguishExpression (./node_modules/acorn/dist/acorn.js:2346:51)
    at NewParser.pp$3.parseExprAtom (./node_modules/acorn/dist/acorn.js:2220:43)
    at NewParser.pp$3.parseExprSubscripts (./node_modules/acorn/dist/acorn.js:2089:21)
    at NewParser.pp$3.parseMaybeUnary (./node_modules/acorn/dist/acorn.js:2066:19)
    at NewParser.pp$3.parseExprOp (./node_modules/acorn/dist/acorn.js:2029:43)
    at NewParser.pp$3.parseExprOps (./node_modules/acorn/dist/acorn.js:2012:93)
    at NewParser.pp$3.parseMaybeConditional (./node_modules/acorn/dist/acorn.js:1993:21)
    at NewParser.pp$3.parseMaybeAssign (./node_modules/acorn/dist/acorn.js:1968:21)
    at NewParser.pp$3.parseExpression (./node_modules/acorn/dist/acorn.js:1933:21)
    at NewParser.pp$1.parseStatement (./node_modules/acorn/dist/acorn.js:877:47)
    at NewParser.pp$1.parseIfStatement (./node_modules/acorn/dist/acorn.js:990:28)
    at NewParser.pp$1.parseStatement (./node_modules/acorn/dist/acorn.js:834:33)
    at NewParser.pp$1.parseTopLevel (./node_modules/acorn/dist/acorn.js:746:23)
    at NewParser.parse (./node_modules/acorn/dist/acorn.js:553:17) ChunkRenderError<EMAIL_ADDRESS>Unexpected token (46:54)
| };
|
| if (false) /* unused pure expression */ undefined && ()/* unused pure expression */ undefined && ()/* unused pure expression */ undefined && ()/* unused pure expression */ undefined && (){ var hyphenatedCache, hyphenPattern, msPattern, oldProcessStyleValue, contentValues, contentValuePattern; }
|
| var shouldWarnAboutInterpolatingClassNameFromCss = /* unused pure expression */ undefined && (true);
    at errorAndCallback (./node_modules/webpack/lib/Compilation.js:2069:26)
    at ./node_modules/webpack/lib/Compilation.js:2148:9
    at ./node_modules/webpack/lib/Cache.js:77:6
    at ./node_modules/webpack/lib/Cache.js:34:11
    at ./node_modules/webpack/lib/cache/IdleFileCachePlugin.js:63:8
    at ./node_modules/webpack/lib/Cache.js:80:6
    at eval (eval at create (./node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:30:1)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:85:5)

error Command failed with exit code 1.

All worked fine up to alpha.23

@apostolos Yeah, can agree.
This was caused by new Deep Scope Analysis, you can disable it with:
  optimization: {
    innerGraph: false
  },

@vxna @apostolos  no need disable something, it is alpha, and need to write about all the errors, preferably with examples, this will fix the errors before the release of the stable version

What is the suggested replacement for the requireEnsure hook in Webpack 5?

@apostolos @vxna 5.0.0-alpha.26 hopefully fixes all issue you've reported
I'm a bit unsure with the buildDependencies problem. If it still occurs I probably need a repro repo.

What is the suggested replacement for the requireEnsure hook in Webpack 5?

You need to create a RuntimeModule and add it to some Chunk. The RuntimeModule can push a function to __webpack_require__.f (use RuntimeGlobals.ensureChunkHandlers) which handles chunk loading.
See these examples:

https://github.com/webpack/webpack/blob/next/lib/web/JsonpTemplatePlugin.js#L195-L202
https://github.com/webpack/webpack/blob/next/lib/web/JsonpChunkLoadingRuntimeModule.js

@sokra v5.0.0-alpha.26 fixes all issues I came across, including buildDependencies. Many thanks!

awesome

@sokra Thanks for the update.
Using<EMAIL_ADDRESS>and<EMAIL_ADDRESS>everything is working smoothly 👍
I also upgrade<EMAIL_ADDRESS>and the perfs are excellent.
Good job 🎉

@sokra
One last (though secondary) issue that I ran through this afternoon.
Until now, I was the size option for moduleIds and chunkIds in our config because the new deterministic one crashed when building our bundle with early 5.0.0-alpha versions.
Using the 5.0.0-alpha.26 version, I've been able to successfully switch back to deterministic for builds. However, when using the CLI to generate a stats.json file with the --profile --json options, it crashes again with an out-of-memory error when they are set to deterministic while it's working fine with the legacy size option.
Here are the logs of the error:
<w> [webpack.Progress] 19101ms building
<i> [webpack.Progress] 213ms finish module graph
<i> [webpack.Progress] 204ms dependencies optimization
<i> [webpack.Progress] 176ms chunk graph
<i> [webpack.Progress] 551ms chunk optimization
<i> [webpack.Progress] 275ms chunk modules optimization
<i> [webpack.Progress] 50ms module reviving
<i> [webpack.Progress] 12ms chunk id optimization
<i> [webpack.Progress] 13ms record modules
<i> [webpack.Progress] 36ms record chunks
<i> [webpack.Progress] 286ms module hashing
<i> [webpack.Progress] 458ms runtime requirements
<i> [webpack.Progress] 87ms hashing
<w> [webpack.Progress] 1912ms chunk assets processing
<w> [webpack.Progress] 13656ms chunk asset optimization
<w> [webpack.Progress] 19084ms after chunk asset optimization
<i> [webpack.Progress] 29ms after seal
<w> [webpack.Progress] 1145ms emitting
<i> [webpack.Progress] 832ms after emitting
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [~/.nvm/versions/node/v8.15.0/bin/node]
 2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [~/.nvm/versions/node/v8.15.0/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [~/.nvm/versions/node/v8.15.0/bin/node]
 4: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [~/.nvm/versions/node/v8.15.0/bin/node]
 5: v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [~/.nvm/versions/node/v8.15.0/bin/node]
 6: v8::String::WriteUtf8(char*, int, int*, int) const [~/.nvm/versions/node/v8.15.0/bin/node]
 7: node::StringBytes::Write(v8::Isolate*, char*, unsigned long, v8::Local<v8::Value>, node::encoding, int*) [~/.nvm/versions/node/v8.15.0/bin/node]
 8: node::Buffer::New(v8::Isolate*, v8::Local<v8::String>, node::encoding) [~/.nvm/versions/node/v8.15.0/bin/node]
 9: node::Buffer::(anonymous namespace)::CreateFromString(v8::FunctionCallbackInfo<v8::Value> const&) [~/.nvm/versions/node/v8.15.0/bin/node]
10: 0xe14ff727a87
11: 0xe14ff77be1a
12: 0xe14fef3edb6
13: 0xe14fee8535f

Im on alpha.26 now, and I am still seeing these errors:
<w> We will try to cache this entry again once in a while or when the cache file is deleted.
<w> [webpack.cache.PackFileCacheStrategy] Caching failed for /module/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[2].oneOf[5].use[1]!node_modules/postcss-loader/src/index.js??ruleSet[1].rules[2].oneOf[5].use[2]!node_modules/sass-loader/dist/cjs.js!src/components/Cards/DocumentCard/DocumentInfoPopover/documentInfoPopover.scss: Error: No serializer registered for ValidationError
<w> We will try to cache this entry again once in a while or when the cache file is deleted.
<w> [webpack.cache.PackFileCacheStrategy] Caching failed for /module/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[2].oneOf[5].use[1]!node_modules/postcss-loader/src/index.js??ruleSet[1].rules[2].oneOf[5].use[2]!node_modules/sass-loader/dist/cjs.js!src/components/DocumentFindings/components/RuleResults/ruleResults.scss: Error: No serializer registered for ValidationError
<w> We will try to cache this entry again once in a while or when the cache file is deleted.

The project hangs and doesn't start. Any ideas on what I should try to edit in my config? Or is this a bug with the alpha.

@jpreynat Not sure if this is a bug. Looks like your stats.json file is just pretty big and you are near the memory limit. Try to increase the memory with max-old-space-size.

@zackify This is only a warning. Seem like some errors/warnings are not serializable. ValidationError looks like the error from schema-util, which happen when passed options are incorrect. Your compilation should not hang because of this. Caching happens after the compilation finished, so it should already be done at this phase. How are you invoking webpack?

@sokra This was indeed the issue. It just happened for the first time when changing the moduleIds option, sorry for the false alarm.
Regarding the new filesystem cache, is it still necessary to turn on the cache option per plugin (for instance terser-webpack-plugin) when it is enabled, or does it handle everything on its own?

@jpreynat you should use cache option for terser-webpack-plugin because many plugins doesn't use webpack cache system yet, when we release new version (only for webpack) it will be in CHANGELOG

Thanks for the clarification @evilebottnawi

The second error seem to origin from https://github.com/chalk/chalk/blob/v1.1.3/index.js#L8
They seem to be using process which is no longer polyfilled in webpack bundles. I wonder why they are using terminal styling anyway here...

@sokra maybe we can move logic for polyfills into plugin with warnings? Sometimes it seems to me that the community is not yet ready to completely move to the browser versions of packages

@sokra @evilebottnawi
I just had a new error with 5.0.0-alpha.26, that I can confirm doesn't happen with 5.0.0-alpha.14 (the one we used before switching). It seems to be related with the new tree-shaking process, since this is a ReferenceError and that doesn't happen in development.
Here is the full error message: Uncaught (in promise) ReferenceError: Block is not defined.
It is correctly imported in the module that throws the error with import { Block } from '<our-module>';.
Block is a class exported from one of our module, and is correctly resolved when using 5.0.0-alpha.14.
I don't know if this can help, but it also worked with 5.0.0-alpha.26 when I was only updating our config, and started to fail after building in CI with a fresh environment (meaning all dependencies where installed from scratch and where updated to their latest versions).

@sokra Friendly ping to know if you have any idea what could cause this issue with the latest release?

@sokra Any ideas on this problem?

Makes the build take a really long time. I'm going to edit the chalk stuff in node modules but since that emfile thing its still not usable yet

@zackify do you use webpack-dev-server?

@evilebottnawi yes

@zackify Can you open issue in webpack-dev-server with reproducible test repo, maybe regression in webpack-dev-middleware

@sokra @evilebottnawi I can confirm that the error described here is still happening with the 5.0.0-alpha.27 version.
Any ideas? 🙏

/cc @sokra

Any ideas? 🙏

@jpreynat You need to give me a few more details? How does the file defining Block look like? Does the problem vanish with optimization.innerGraph: false?

@zackify OSX has a relative low open file limit and watching many files in node_modules can use up this limit.
See here how to adjust your system for higher number of files
or
Try to ignore i. e. node_modules from watching -> watchOptions.ignore, but in this case you have to restart webpack when modifying node_modules (i. e. with npm/yarn).

https://github.com/webpack/webpack/releases/tag/v5.0.0-alpha.28 should allow to run mini-css-extract-plugin (with deprecation messages), if you want to give it a go...

@sokra Thanks for the answer.
Indeed, setting optimization.innerGraph: false makes the error disappear.
Block in our code is actually imported from another one of our published modules.
After further investigation, here are the differences when switching innerGraph on and off.
Our file actually imports many classes from the same module:
// crashing-file.ts
import { Block, Inline, Text, Document } from 'some-module';

Block.doSomething();
Inline.doSomething();
Text.doSomething();
Document.doSomething();

All classes are exported in the same way from the required module:
// some-module main index.js
class Block { ... }
class Text { ... }
class Inline { ... }
class Document { ... }

export { Block, Text, Inline, Document };

When the innerGraph: false option is set, all classes are correctly resolved from the required module in the compiled code:
// compiled-innerGraph-false.js
var r=n(6744);
// ...
r.Block.doSomething();
r.Inline.doSomething();
r.Text.doSomething();
r.Document.doSomething();

However, when innerGraph is not set to false, the compiled code look like this:
// compiled-innerGraph-true.js
var r=n(6744);
// ...
Block.doSomething();
Inline.doSomething();
Text.doSomething();
r.Document.doSomething();

So Document is correctly resolved, but not the other ones.
Any ideas?

Hmm I see. Seems like the problem is in compiled-innerGraph-true.js. Where in this file is Block.doSomething();. Is it at root of the module or wrapped inside of functions, classes?

@sokra All imports are used inside of functions, like so:
import { Block, Inline, Document } from 'some-module';

function doSomethingWithBlock(obj) {
    return Block.doSomething(obj);
}

function doSomethingWithInline(obj) {
    return Inline.doSomething(obj);
}

function doSomethingWithDocument(obj) {
    return Document.doSomething(obj);
}

If this can help, the ones that are failing to resolve (Block, Inline and Text) are only used in an exported function that uses a switch statement, while Document (which resolved correctly in the compiled code) is also used in another exported function.
Here is how our whole file looks like globally:
import { Block, Inline, Document } from 'some-module';

// Local functions
function doSomethingWithBlock(obj) {
    return Block.doSomething(obj);
}

function doSomethingWithInline(obj) {
    return Inline.doSomething(obj);
}

function doSomethingWithDocument(obj) {
    return Document.doSomething(obj);
}

// Exported functions
function doSomething(obj) {
    const type = getType(obj);

    switch (type) {
        case 'document':
             return doSomethingWithDocument(obj);
        case 'block':
             return doSomethingWithBlock(obj);
        case 'inline':
             return doSomethingWithInline(obj);
        default:
             throw new Error();
    }
}

function useDocument(obj) {
    return doSomethingWithDocument(obj);
}

export { useDocument };
export default doSomething;

@jpreynat hmm I was unable to create a case where this problem happens. Could you create a small repo to reproduce this problem?

@jpreynat fixed by https://github.com/webpack/webpack/pull/9762

@jpreynat here you are: https://github.com/webpack/webpack/releases/tag/v5.0.0-alpha.29

@sokra
Thanks for the update.
However, while testing it all my builds now get stuck at some point, not always on the same file though.
Passing innerGraph: false makes the build pass as expected, but as soon as it is true, it get stuck before the end.
For instance:
60% building 4/8 entries 1521/1812 modules 100 active ./node_modules/lodash/identity.js

or
66% building 4/8 entries 2175/2315 modules 100 active ./node_modules/lodash/_baseMap.js

Could you try to run it with parallelism: 1 to see on which module it's hanging.

Sorry about the back and forth with the new innerGraph feature. It's good that these issue come up in these alpha tests so we can get them fixed early...

No worries @sokra, I'm glad to test the new improvements. It seems very promising, and it currently seems to reduce our total bundle size from 6.74MB to 5.75MB, which is huge.
When running with parallelism: 1, it turns out that it's the exact file that I described the last time that hangs. The exact one that has the import { Block, Inline, Document } and switch statements.
Any ideas what I could test to see what's wrong with it?

Best of you could send me the file. The innerGraph analysis is on module base so this single file should be enough to get the problem. You can also send it per mail if you want to do it in private.
Otherwise you can try to debug the problem yourself. My guess is it hangs in InnerGraphPlugin in the flatten graph loop in the finalise plugin. You can console.log(innerGraph) here to get a structure of the module. It's analysing which imports and top level symbols (key) are used by exports and other top level symbols (value). Before the flattening process it's the raw structure as parsed from the source code. After the flattening the value is either a list of exports or true for "always used" or undefined for "never used".
You file seem to have some kind of circular references between top level symbols which probably cause the flattening process to never finish. I'm unsure how this happens as I was unable to figure out which graph could cause this.
But maybe it's some completely different problem... So first step could be to check if it's really hanging here.
You should be able to copy the problematic file into a new project and point all imports to empty modules and you should still get the issue. That makes it easier to debug the inner graph stuff as it's called for every module.

@sokra I was able to replicate the issue in the repo that I shared with you.
I just updated it with our use case so you can easily run tests against it.
Thanks again for your time 🙏

Webpack 5.0.0-alpha.29 transforms this lines into these:
module.exports = {
module.exports symbol: publicPath + symbolUrl,
	view: publicPath + viewUrl,
	viewBox: '0 0 149 31.08',
	title: '',
	toString: function () {
		return JSON.stringify(this.view);
	}
};

Th error which is caused by terser if enabled:
ERROR in chunks/921.e4b4998f.js from Terser
Unexpected token punc «.», expected punc «,» [chunks/921.e4b4998f.js:20,15] Error: chunks/921.e4b4998f.js from Terser
Unexpected token punc «.», expected punc «,» [chunks/921.e4b4998f.js:20,15]
    at Function.buildError (C:\Users\username\Projects\projectname\node_modules\terser-webpack-plugin\dist\index.js:96:14)
    at completedTasks.forEach (C:\Users\username\Projects\projectname\node_modules\terser-webpack-plugin\dist\index.js:294:48)
    at Array.forEach (<anonymous>)
    at TerserPlugin.optimizeFn (C:\Users\username\Projects\projectname\node_modules\terser-webpack-plugin\dist\index.js:269:22)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Without terser there's no error and the build finishes successfully, but the code is malformed still.

@thasmo what is version terser-webpack-plugin?

@evilebottnawi Oh, dang - seems I'm still on the old version (1.4.x); will check asap! Thanks for bringing this to my attention.

@jpreynat fixed by #9777
@thasmo should be fixed by #9778
released https://github.com/webpack/webpack/releases/tag/v5.0.0-alpha.30

Thanks @sokra 👍
I will test it first thing tomorrow morning and let you know.

@sokra Thanks for the fix, it seems to have solved the issue about the weirdly nested module.exports statement.

One issue I still have (and I might also have it with webpack 4) is the creation of many very small chunks, one which e.g. looks like this:
(window.webpackJsonp=window.webpackJsonp||[]).push([[849],{530:(w,p,s)=>{"use strict";s.r(p);s(713),s(510)}}]);

I assume that s(713),s(510) are references/includes to other chunks but those do not exists, afaik.
Also, there's a styles.js which gets created and only holds lots of those function calls:
(window.webpackJsonp=window.webpackJsonp||[]).push([[532],{5:()=>{},21:()=>{},24:()=>{},28:()=>{},29:()=>{},30:()=>{},37:()=>{},42:()=>{},44:()=>{},49:()=>{},52:()=>{},63:()=>{},75:()=>{},80:()=>{},88:()=>{},95:()=>{},103:()=>{},104:()=>{},105:()=>{},108:()=>{},115:()=>{},127:()=>{},131:()=>{},135:()=>{},144:()=>{},153:()=>{},160:()=>{},168:()=>{},170:()=>{},171:()=>{},172:()=>{},192:()=>{},193:()=>{},197:()=>{},198:()=>{},199:()=>{},200:()=>{},202:()=>{},223:()=>{},240:()=>{},242:()=>{},262:()=>{},264:()=>{},271:()=>{},275:()=>{},278:()=>{},280:()=>{},295:()=>{},299:()=>{},309:()=>{},316:()=>{},322:()=>{},324:()=>{},326:()=>{},335:()=>{},341:()=>{},346:()=>{},356:()=>{},357:()=>{},366:()=>{},367:()=>{},370:()=>{},379:()=>{},385:()=>{},387:()=>{},396:()=>{},397:()=>{},399:()=>{},402:()=>{},404:()=>{},405:()=>{},410:()=>{},413:()=>{},417:()=>{},422:()=>{},444:()=>{},446:()=>{},454:()=>{},460:()=>{},465:()=>{},466:()=>{},468:()=>{},470:()=>{},476:()=>{},477:()=>{},485:()=>{},501:()=>{},502:()=>{},510:()=>{},516:()=>{},522:()=>{},527:()=>{},534:()=>{},546:()=>{},547:()=>{},551:()=>{},562:()=>{},573:()=>{},576:()=>{},577:()=>{},586:()=>{},596:()=>{},602:()=>{},615:()=>{},616:()=>{},634:()=>{},646:()=>{},653:()=>{},656:()=>{},657:()=>{},669:()=>{},694:()=>{},707:()=>{},713:()=>{},728:()=>{},732:()=>{},733:()=>{},734:()=>{},736:()=>{},741:()=>{},745:()=>{},752:()=>{},754:()=>{},762:()=>{},764:()=>{},766:()=>{},770:()=>{},772:()=>{},784:()=>{},790:()=>{},795:()=>{},800:()=>{},801:()=>{},802:()=>{},822:()=>{},824:()=>{},854:()=>{},871:()=>{},885:()=>{},891:()=>{},906:()=>{},910:()=>{},914:()=>{},915:()=>{},922:()=>{},923:()=>{},925:()=>{},929:()=>{},941:()=>{},948:()=>{},954:()=>{},959:()=>{},961:()=>{},967:()=>{},977:()=>{},982:()=>{},997:()=>{}}]);

Has this something to do with #7300 which should have been fixed via #9040?

@thasmo This is not webpack 5 related. There is a PR to remove the empty JS module for CSS in the mini-css-extract-plugin. You can follow that.
webpack 5 improves one thing: empty js chunks are no longer created. Empty means no module at all.

@sokra It's now working perfectly.
Thanks again for the release 👍

Awesome...

Getting quite some deprecation messages; is there a way to find out where those deprecated calls actually occur, so I can change them or notify package maintainers to handle them? Thanks!

Do you have the stack trace?

@evenstensberg No, it's just printing this to the console when running webpack:
(node:15072) DeprecationWarning: Compilation.hooks.normalModuleLoader was moved to NormalModule.getCompilationHooks(compilation).loader
(node:15072) DeprecationWarning: Module.id: Use new ChunkGraph API
(node:15072) DeprecationWarning: Chunk.modulesIterable: Use new ChunkGraph API
(node:15072) DeprecationWarning: Module.updateHash: Use new ChunkGraph API
(node:15072) DeprecationWarning: ChunkGroup.getModuleIndex2 was renamed to getModulePostOrderIndex
(node:15072) DeprecationWarning: chunk.files was changed from Array to Set (using Array method 'push' is deprecated)
(node:15072) DeprecationWarning: Compilation.chunks was changed from Array to Set (using Array method 'push' is deprecated)

@thasmo Are you using the mini-css-extract-plugin? I think it currently triggers a lot of those.

node --trace-deprecation prints stack traces

Maybe plugins will trigger a lot deprecation warnings... You can hide them with node --no-deprecation if they annoy you.
They aren't too bad currently, plugin should eventually get rid of them... These deprecated APIs will be removed with webpack 6.
Yes mini-css-extract-plugin trigger a lot, and we will update this plugin before final release.

https://github.com/webpack/webpack/releases/tag/v5.0.0-alpha.31
This version contains a larger refactoring (and more deprecations), so it would be nice if you could test it again.
Once this is version is working we can move to beta phase 🎉

Here is a cool example of webpack generating a bundle without runtime in module mode:
https://github.com/webpack/webpack/tree/f25906fd2fd0bbcf472d9d44dcd8d6a92e3fbe95/examples/module

Works. Noticed some more deprecation messages indeed. Didn't test the html-webpack-plugin tho.

Seems to be working fine 🎉, just one interesting thing regarding new optimisations:
I see some new vendors-node_modules_*_* chunks. In production those come as 406 or so.
I suppose, these are chunks containing modules from node_module, which are included in lazy-load chunks, but not defined as vendor module?

I see some new vendors-node_modules_*_* chunks

In development chunks without name are automatically named after content. So this chunk probably contains the module node_modules_*_* + dependencies. The vendors- prefix means it was created by the default splitChunks configuration for vendor splitting.
You can use stats.chunks: true to get more information about chunks. stats.chunkOrigins: true also shows were the chunk is requested from.

Works.

Seems to be working fine 🎉

That makes me happy... 🎉

The vendors- prefix means it was created by the default splitChunks configuration for vendor splitting.

That seems to answer the question, and confirm my thoughts/suspicions. thanks!

Thanks for your awesome feedback and testing.
We enter beta phase now -> https://github.com/webpack/webpack/issues/9802

Getting the following error when compiling with webpack 5.0.0-beta.0:

Module build failed (from ./node_modules/svg-sprite-loader/lib/loader.js):
Error: Cannot find module 'webpack/lib/RuleSet'

Found this reference from svg-sprite-loader
RuleSet.js file is missing from my local node_modules/webpack/lib
Is this a webpack issue or svg-sprite-loader ? Any workarounds?
Thanks

 compilation.hooks.htmlWebpackPluginAlterChunks = new SyncWaterfallHook(['chunks', 'objectWithPluginRef']);
                                                       ^

TypeError: Cannot add property htmlWebpackPluginAlterChunks, object is not extensible

I have the same issues. and i am using<EMAIL_ADDRESS>and<EMAIL_ADDRESS>@capaj Have you find some solution about this? Just notice the issues about html-webpack-plugin https://github.com/jantimon/html-webpack-plugin/issues/1130
But it's still reoccur on my local..

getting same error with<EMAIL_ADDRESS><EMAIL_ADDRESS>and<EMAIL_ADDRESS>(node:27925) UnhandledPromiseRejectionWarning: TypeError: Cannot add property htmlWebpackPluginAlterChunks, object is not extensible
    at compiler.hooks.compilation.tap.compilation (/Users/iuliasoimaru/Documents/www/web/node_modules/html-webpack-plugin/index.js:59:56)
    at Hook.eval [as call] (eval at create (/Users/iuliasoimaru/Documents/www/web/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:7:1)

plugin:
new HtmlWebpackPlugin({
            showErrors: false,
            template: path.resolve(
                path.resolve(ROOT_DIR, 'dir', name),
                'template.html'
            ),
            favicon: path.resolve(
                path.resolve(ROOT_DIR, 'dir', name),
                'assets/favicon.ico'
            ),
            filename: `${name}.index.html`,
        }),

@zpc7 @Iulia-Soimaru  its fixed in the new releases, latest is currently https://github.com/jantimon/html-webpack-plugin/commit/bf017f31e29161bdcafb03cff90fb635ed54438a 4 beta 11
yarn add html-webpack-plugin@next -D

when did you start to update "mini-css-extract-plugin" , I wait it for a year!  May be I will use rollup instead webpack!

@yejinjian it will be after beta stabilization + a lot of features and fixes

(node:60084) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be one of type string, TypedArray, or DataView. Received type undefined
at Hash.update (internal/crypto/hash.js:58:11)
at BulkUpdateDecorator.update (/test/node_modules/webpack/lib/util/createHash.js:49:14)

"webpack": "^5.11.0",
ℹ ｢wds｣: 404s will fallback to /index.html
87% sealing module hashing(node:60084) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be one of type string, TypedArray, or DataView. Received type undefined
at Hash.update (internal/crypto/hash.js:58:11)
at BulkUpdateDecorator.update (/test/node_modules/webpack/lib/util/createHash.js:49:14)
at NormalModule.updateHash (/test/node_modules/webpack/lib/NormalModule.js:1062:8)
at Compilation.createModuleHashes (/test/node_modules/webpack/lib/Compilation.js:2710:12)
at hooks.optimizeChunkModules.callAsync.err (/test/node_modules/webpack/lib/Compilation.js:2048:11)
at Hook.eval [as callAsync] (eval at create (/test/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), :12:1)
at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/test/node_modules/webpack/node_modules/tapable/lib/Hook.js:18:14)
at hooks.optimizeTree.callAsync.err (/test/node_modules/webpack/lib/Compilation.js:2008:36)
at eval (eval at create (/test/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), :22:1)
at handleCompilationDonePromise.then (/test/node_modules/html-webpack-plugin/lib/cached-child-compiler.js:237:53)
(node:60084) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:60084) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

hi! help me please!
for (const [filePath, date] of times) {
^
TypeError: times is not iterable
at C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\ts-loader\dist\watch-run.js:26:44
at Hook.eval [as callAsync] (eval at create (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\tapable\lib\HookCodeFactory.js:33:10), :5:1)
at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\tapable\lib\Hook.js:18:14)
at run (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\Watching.js:66:33)
at C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\Watching.js:120:5
at C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\HookWebpackError.js:69:3
at Hook.eval [as callAsync] (eval at create (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\tapable\lib\HookCodeFactory.js:33:10), :4:1)
at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\tapable\lib\Hook.js:18:14)
at Cache.endIdle (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\Cache.js:140:22)
at Watching._go (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\Watching.js:117:24)
what is this??

hi! help me please!
for (const [filePath, date] of times) {
^
TypeError: times is not iterable
at C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\ts-loader\dist\watch-run.js:26:44
at Hook.eval [as callAsync] (eval at create (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\tapable\lib\HookCodeFactory.js:33:10), :5:1)
at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\tapable\lib\Hook.js:18:14)
at run (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\Watching.js:66:33)
at C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\Watching.js:120:5
at C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\HookWebpackError.js:69:3
at Hook.eval [as callAsync] (eval at create (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\tapable\lib\HookCodeFactory.js:33:10), :4:1)
at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\tapable\lib\Hook.js:18:14)
at Cache.endIdle (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\Cache.js:140:22)
at Watching._go (C:\Users\lenovo\Documents\WWW\skillbox\react.js\node_modules\webpack\lib\Watching.js:117:24)
what is this??

@Mikhayle I think you use old version of ts-loader, please update, if it is not help, pelase open an issue in ts-loader repo

@Mikhayle I think you use old version of ts-loader, please update, if it is not help, pelase open an issue in ts-loader repo

@17biubiu I solved this problem by updating my babel-loader to 8.x and babel-core to @babel/core 7.x

4. circular-dependency-plugin

Can anybody tell me, how can I remove circular-dependency-plugin? I am getting "Error: module property was removed from Dependency (use compilation.moduleGraph.getModule(dependency) instead)" error in my angular project because of webpack. Thanks in advanced.