Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

webpack 5 beta feedback #9802

Open
sokra opened this issue Oct 11, 2019 · 225 comments
Labels

Comments

@sokra
Copy link
Member

@sokra sokra commented Oct 11, 2019

馃帀 Thanks for being brave and donating your valuable time to testing unfinished beta software 馃帀

webpack 5 is in beta phase now. This means major changes and features are done. Major breaking changes have been added. Basic backward-compatibility has been added.

We want to use the beta phase to do the following:

  • Let a boarder range of users test the beta version.
  • Find bugs in new features.
  • Find regressions in old features.
  • Find places where a compat-layer can be added to avoid breaking changes.
  • Improve the migration guide and changelog.

We want to reach these goals after the beta phase:

  • Old features are very stable
  • New features are a bit stable
  • Backward-compatibility layer allows most existing plugins/loader to work unmodified (potentially with deprecation warnings)
  • There clear way how to migrate from webpack 4 to 5
  • There are experimental webpack 5 branches for higher-level tools (like angular-cli, vue-cli, create-react-app, ...) (at least 2)

To help with testing you can do the following:

  • Always test with the latest webpack beta version, as problems might already be fixed there
  • When using webpack directly:
    • Follow the migration guide
    • Report or add missing steps in the migration guide
    • Report problems during the migration
    • Report problems with the build after the migration
  • When using a higher-level tool:
    • Check if there is a branch/Pull Request for webpack 5
    • Follow guide there
    • Report problems in the Pull Request
  • Make sure to also report (positive) experience
    • Performance comparison
    • Size comparison
    • DX comparison
  • Try new features
    • Enable persistent caching -> guide
    • Enable Top Level Await
    • Enable the new asset module type
    • Enable Long Term Caching
    • Try to break filesystem watching
  • Trace back deprecation warnings with node --trace-deprecation
    • Help upgrading plugins/loaders
  • Make sure to follow beta releases
    • Retest newer version to avoid regressions in beta versions
  • Consider sponsoring webpack when this version
    • increases your productivity with better build performance
    • increases your productivity with better developer experience
    • increases your consumer happiness with better application performance
    • make you happy in some other way...

Known problems:

Planned breaking changes:

  • devtool options will be more restrictive
  • Internal HMR API for plugins will probably change
  • Disable some webpack-only syntax by default: require.ensure, require.include
  • terser-webpack-plugin will be upgraded
  • cache.store != "pack" will be removed
@sokra sokra pinned this issue Oct 11, 2019
@sokra sokra mentioned this issue Oct 11, 2019
15 of 19 tasks complete
@hiroppy hiroppy added the webpack-5 label Oct 11, 2019
@miraage

This comment has been minimized.

Copy link

@miraage miraage commented Oct 11, 2019

Automatic Node.js Polyfills Removed
Please provide us with feedback whether you like or dislike the above mentioned change

Many thanks for that from my side. I can not understand how people could write frontend code without realizing what dependencies they actually use..

@Andarist

This comment has been minimized.

Copy link

@Andarist Andarist commented Oct 11, 2019

Do not edit files in node_modules directly unless you opt-out of this optimization with cache.managedPaths: []

This is generally fine, but it would be really great if we could opt-out of this with some flag passed into the webpack. There are cases when editing node_modules helps in debugging problems in dependencies and editing the config to opt-out of this for a "brief" moment is not really that ergonomic. For context e.g. Jest allows this with --no-cache

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Oct 11, 2019

For context e.g. Jest allows this with --no-cache

You can request that for webpack-cli, which can set cache: false.

@thasmo

This comment has been minimized.

Copy link

@thasmo thasmo commented Oct 11, 2019

Diving into updating our webpack-based tool and I read about setting these for HTTP2:
maxInitialRequests: 30, maxAsyncRequests: 30, maxSize: 100_000
Where do these numbers come from; has this been tested or something? Thanks!

@TchernyavskyDaniil

This comment has been minimized.

Copy link

@TchernyavskyDaniil TchernyavskyDaniil commented Oct 11, 2019

what about options like a --mode production, --env.file and etc. Is that dep?

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Oct 11, 2019

what about options like a --mode production, --env.file and etc. Is that dep?

This is currently unhandled. We need to find a solution for this in the CLI.

@7rulnik

This comment has been minimized.

Copy link

@7rulnik 7rulnik commented Oct 11, 2019

I have a node target and this optimization configuration

 optimization: {
    chunkIds: 'named',
    splitChunks: {
        chunks: 'all'
    },
}

and got this error:

89% chunk assets processingError: Conflict: Multiple chunks emit assets to the same filename server.js (chunks server and vendors-node_modules_alfabank_base-layer_index_js-node_modules_alfabank_container_index_js-no-8997df)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compilation.js:2317:12
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Cache.js:85:5
    at Hook.eval [as callAsync] (eval at create (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Cache.get (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Cache.js:70:18)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compilation.js:2277:18
    at arrayEach (/Users/7rulnik/projects/alfabank/assr/node_modules/neo-async/async.js:2405:9)
    at Object.each (/Users/7rulnik/projects/alfabank/assr/node_modules/neo-async/async.js:2846:9)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compilation.js:2270:14
    at symbolEach (/Users/7rulnik/projects/alfabank/assr/node_modules/neo-async/async.js:2444:9)
    at Object.each (/Users/7rulnik/projects/alfabank/assr/node_modules/neo-async/async.js:2849:16)
    at Compilation.createChunkAssets (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compilation.js:2248:12)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compilation.js:1539:10
    at Hook.eval [as callAsync] (eval at create (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:9:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/node_modules/tapable/lib/Hook.js:18:14)
    at Compilation.seal (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compilation.js:1433:27)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compiler.js:770:19
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compilation.js:1357:4
    at _next1 (eval at create (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:21:1)
    at eval (eval at create (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:42:1)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/neo-async/async.js:2830:7
    at Object.each (/Users/7rulnik/projects/alfabank/assr/node_modules/neo-async/async.js:2850:39)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/FlagDependencyExportsPlugin.js:216:18
    at /Users/7rulnik/projects/alfabank/assr/node_modules/neo-async/async.js:2830:7
    at Object.each (/Users/7rulnik/projects/alfabank/assr/node_modules/neo-async/async.js:2850:39)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/FlagDependencyExportsPlugin.js:40:16
    at Hook.eval [as callAsync] (eval at create (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:38:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/node_modules/tapable/lib/Hook.js:18:14)
    at Compilation.finish (/Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compilation.js:1328:28)
    at /Users/7rulnik/projects/alfabank/assr/node_modules/webpack/lib/Compiler.js:765:18
    at processTicksAndRejections (internal/process/task_queues.js:75:11)
/Users/7rulnik/projects/alfabank/assr/node_modules/.bin/webpack process exited with code 1

Without splitChunks build works as expected

 optimization: {
    chunkIds: 'named',
}
@TchernyavskyDaniil

This comment has been minimized.

Copy link

@TchernyavskyDaniil TchernyavskyDaniil commented Oct 11, 2019

what about options like a --mode production, --env.file and etc. Is that dep?

This is currently unhandled. We need to find a solution for this in the CLI.

Could you explain me another way, add full path to config prod/dev and about env.file ...?

For example:

Build client

./node_modules/webpack/bin/webpack.js --mode production --env.file=production --env.folder=$BUILD_FOLDER

Build server

./node_modules/webpack/bin/webpack.js --env.file=ssr.production --env.folder=$BUILD_FOLDER

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Oct 11, 2019

Where do these numbers come from; has this been tested or something? Thanks!

@thasmo It's an estimated guess. Probably depends on the application.

maxInitialRequests: 30, maxAsyncRequests: 30

These are pretty high limits. I think no normal application will run into these limits at all. I uses 30 instead of Infinity to have some kind of parachute for extreme edgecases. (Infinity has a little performance benefit, so that's probably also fine if you are not at these edgecases)

maxSize: 100_000

The minSize defaults to 30kb. With this config chunks will be between 30kb and 100kb. The algorithm work the way that chunks bigger than maxSize are split into two parts. The splitting point is chosen in a deterministic way based on module names. The split point can't be in the first 30kb and can't be in the last 30kb, so it has about 40kb to move. Smaller maxSizes give it less room to move, which makes it less deterministic, which hurts long term caching. Bigger maxSize makes the chunks bigger, which hurts long term caching. Difficult to find a perfect value, depends on the app and which changes you do. As a rule of thumb I thought maxSize = 3 * minSize could be a good idea.

If someone want to do deeper investigations here, that would be interesting.

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Oct 11, 2019

Multiple chunks emit assets to the same filename server.js

@7rulnik Did you set output.filename: "server.js" or used the default output.filename: "[name].js"

@thasmo

This comment has been minimized.

Copy link

@thasmo thasmo commented Oct 11, 2019

@sokra Thanks a lot for the explanation.

@7rulnik

This comment has been minimized.

Copy link

@7rulnik 7rulnik commented Oct 11, 2019

@sokra yep, it was server.js and entry was server.
I tried [name].js 鈥 now it works. Is it the recommended approach?

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Oct 11, 2019

Could you explain me another way, add full path to config prod/dev and about env.file ...?

@TchernyavskyDaniil I'm not sure if I understood the question correctly. Was this related to Persistent Caching?

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Oct 11, 2019

I tried [name].js 鈥 now it works. Is it the recommended approach?

@7rulnik When chunks are splitted (or multiple entrypoints are used) output.filename affects multiple chunk. You can give multiple chunks the same filename. A constant output.filename won't work in these cases.

@thasmo

This comment has been minimized.

Copy link

@thasmo thasmo commented Oct 11, 2019

About the persistent cache configuration; how would it look like if I add custom/other files?

cache: {
  // 1. Set cache type to filesystem
  type: "filesystem",
  
  buildDependencies: {
    // 2. Add your config as buildDependency to get cache invalidation on config change
    config: [__filename],
  
    // 3. If you have other things the build depends on you can add them here
    // Note that webpack, loaders and all modules referenced from your config are automatically added
    anyKeyHere: ['/absolute/path/'], // ?
  }
}

Would it take a regex/glob too?

In that sense; is there documentation for v5 already somewhere?

@TchernyavskyDaniil

This comment has been minimized.

Copy link

@TchernyavskyDaniil TchernyavskyDaniil commented Oct 11, 2019

Could you explain me another way, add full path to config prod/dev and about env.file ...?

@TchernyavskyDaniil I'm not sure if I understood the question correctly. Was this related to Persistent Caching?

Just a another way to build like that :)

Build client

./node_modules/webpack/bin/webpack.js --mode production --env.file=production --env.folder=$BUILD_FOLDER

Build server

./node_modules/webpack/bin/webpack.js --env.file=ssr.production --env.folder=$BUILD_FOLDER

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Oct 11, 2019

Would it take a regex/glob too?

No, only files: something, or folders: something/. It will be resolved so it could be a node_modules or file without extension.

In that sense; is there documentation for v5 already somewhere?

Not that much. The Changelog has much info. There is a work in progress branch here: https://github.com/webpack/webpack.js.org/tree/next

@7rulnik

This comment has been minimized.

Copy link

@7rulnik 7rulnik commented Oct 11, 2019

@sokra also build time increased by ~25%. I can provide the graphs from ProfilingPlugin. Should I?

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Oct 11, 2019

Should I?

@7rulnik yep. Could you create a new issue with your case + config?

@thasmo

This comment has been minimized.

Copy link

@thasmo thasmo commented Oct 11, 2019

Noticed when using eslint-loader it prints this to the terminal:

  assets\base\scripts\application\components\component.ts:14:18
  鈥   5:24  Unexpected any. Specify a different type.  @typescript-eslint/no-explicit-any
  鈥   6:27  Unexpected any. Specify a different type.  @typescript-eslint/no-explicit-any
  鈥   7:25  Unexpected any. Specify a different type.  @typescript-eslint/no-explicit-any
  鈥  16:47  Unexpected any. Specify a different type.  @typescript-eslint/no-explicit-any
  脳  14:18  Unexpected empty method run.               @typescript-eslint/no-empty-function

  4 warnings
  1 error

    at emitError (C:\Users\user\Projects\project\node_modules\webpack\lib\NormalModule.js:273:6)
    at Linter.printOutput (C:\Users\user\Projects\project\node_modules\eslint-loader\dist\Linter.js:95:5)
    at cache (C:\Users\user\Projects\project\node_modules\eslint-loader\dist\cacheLoader.js:46:14)
    at C:\Users\user\Projects\project\node_modules\loader-fs-cache\index.js:122:24
    at Gunzip.cb (C:\Users\user\Projects\project\node_modules\loader-fs-cache\index.js:47:14)
    at Gunzip.zlibBufferOnEnd (zlib.js:131:10)
    at Gunzip.emit (events.js:203:15)
    at Gunzip.EventEmitter.emit (domain.js:448:20)
    at endReadableNT (_stream_readable.js:1145:12)
    at process._tickCallback (internal/process/next_tick.js:63:19)

Any idea why the stack is printed as well? The call stack should not be printed actually, I guess - only the linting errors should be printed.

@7rulnik

This comment has been minimized.

Copy link

@7rulnik 7rulnik commented Oct 11, 2019

@sokra issue about build time #9807

@thasmo

This comment has been minimized.

Copy link

@thasmo thasmo commented Oct 12, 2019

Got lots of these logs on the console when using the new filesystem caching:

<w> [webpack.cache.PackFileCacheStrategy] Caching failed for /module/C:\Users\thasmo\Projects\project\node_modules\mini-css-extract-plugin\dist\loader.js!C:\Users\thasmo\Projects\project\node_modules\css-loader\dist\cjs.js??ruleSet[1].rules[0].use[1]!C:\Users\thasmo\Projects\project\node_modules\postcss-loader\src\index.js??ruleSet[1].rules[0].use[2]!C:\Users\thasmo\Projects\project\node_modules\resolve-url-loader\index.js??ruleSet[1].rules[0].use[3]!C:\Users\thasmo\Projects\project\node_modules\sass-loader\dist\cjs.js??ruleSet[1].rules[0].use[4]!C:\Users\thasmo\Projects\project\assets\components\sitemap\styles\base.scss: Error: No serializer registered for CssDependency
<w> We will try to cache this entry again once in a while or when the cache file is deleted.

What do they mean; can I fix/disable them?

@thasmo

This comment has been minimized.

Copy link

@thasmo thasmo commented Oct 12, 2019

Also encountering an issue described in webpack-contrib/stylelint-webpack-plugin#187.

@dreyks

This comment has been minimized.

Copy link

@dreyks dreyks commented Oct 12, 2019

Tried caching option and looks like it works only every other time. Continuously running the build without changing anything: one build is cached another one is not

@thasmo

This comment has been minimized.

Copy link

@thasmo thasmo commented Oct 13, 2019

About persistent caching; can it be used in production and development mode and even with watch, or are there limitations? If not, I'm looking forward enabling it in general.

@artem-malko

This comment has been minimized.

Copy link

@artem-malko artem-malko commented Nov 17, 2019

@sokra Hi, it's me again) Version: webpack 5.0.0-beta.6 New problem with cache.
Log message:

<w> [webpack.cache.PackFileCacheStrategy] Restoring failed for /SourceMapDevToolPlugin/styles.ltr.d8d057ebbd885a7a7b8b26dbbd2cd1c5.css from pack: TypeError: this._obj.updateHash is not a function
<w> [webpack.cache.PackFileCacheStrategy] Restoring failed for /SourceMapDevToolPlugin/styles.rtl.d8d057ebbd885a7a7b8b26dbbd2cd1c5.css from pack: TypeError: this._obj.updateHash is not a function

I have my own plugin to work with css-in-js, you can get its code from gist on github. I have a loader too, but I think, it will be useless for you.
So, is it a problem with my plugin or with webpack itself?
Warn messages appear on dev mode only. In prod mode there is no any messages.

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 17, 2019

@artem-malko the problem is mentioned as Todo comment in your plugin: @TODO use https://github.com/webpack/webpack-sources

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 17, 2019

but, now it treats my yarn packages as node_module and will not apply their changes (somehow, it does recompile, but not applying the changes)

@AlonMiz I wonder why this doesn't work by default. Your projects are not really in node_modules, they are just symlinks into your workspace. So as they are not in node_modules, managedPaths should not apply (as long you didn't set resolve.symlinks: false)

@AlonMiz

This comment has been minimized.

Copy link

@AlonMiz AlonMiz commented Nov 17, 2019

@sokra you are right. it turns out to be an issue with awesome-typescript-loader i removed the useCache property and it went back to normal.

@artem-malko

This comment has been minimized.

Copy link

@artem-malko artem-malko commented Nov 18, 2019

@sokra thx, with webpack-sources works like a charm)
But, there is another problem with cache. As you can see from plugin (I've updated the gist with plugin) I use interpolateName to replace [contenthash] to string with hash. So, it works without cache, but with cache it is not replaced.
The first build (when there is no cache) is correct, [contenthash] is replaced with hash string, but the second build is incorrect(

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 18, 2019

@artem-malko not sure how this storeInstance.getStyles() works. Maybe it's empty when all modules that generate styles are cached. How are styles put into the store?

@artem-malko

This comment has been minimized.

Copy link

@artem-malko artem-malko commented Nov 18, 2019

@sokra yeah, you are right! I've created gist with loader. In loader I collect all css in Store and then use this Store in plugin. As I understand, shared Store is a problem)
Where can I read about correct implementation of shared code between loader and plugin with cache in webpack 5?) Should I start from https://github.com/webpack/changelog-v5/blob/master/README.md#extensible-caching?

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 18, 2019

@artem-malko You could store the loader results in module.buildInfo[SOME_KEY]. That's stored into the cache. In the plugin iterate over all modules and extract styles from buildInfo.

EDIT: You can get the module in loader with this._module

@artem-malko

This comment has been minimized.

Copy link

@artem-malko artem-malko commented Nov 18, 2019

@sokra this._module looks like something private)

In the plugin iterate over all modules

I think, It's might be quite slow to iterate over all modules, isn't it? I don't know, maybe it's a common approach for webpack 5 to store data in module) I thought, there will be (or it is created) API for cache store) I found Extensible Caching only.

@ogonkov

This comment has been minimized.

Copy link

@ogonkov ogonkov commented Nov 19, 2019

@artem-malko You could store the loader results in module.buildInfo[SOME_KEY]. That's stored into the cache. In the plugin iterate over all modules and extract styles from buildInfo.

EDIT: You can get the module in loader with this._module

Wish it would be documented somewhere

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 19, 2019

this._module looks like something private

@artem-malko True, but many plugin loader combinations use it, so you are probably fine.

If you want to know the nicer solution:

  1. Via your plugin add a new method to the loader context: NormalModule.getCompilationHooks(compilation).loader.tap(...).
  2. From your loader call this new method. (You probably want to display a nice error message, if the loader is used without the plugin)
  3. In the method you have access to module from the hook arguments.
@artem-malko

This comment has been minimized.

Copy link

@artem-malko artem-malko commented Nov 19, 2019

@sokra thx. Approach with store data in buildInfo works nice)

As I understand, the nicer solution resolves this._module problem (access to private filed). I have to add my data to buildInfo of module and then read it from module in plugin. I can't share some abstract store between plugin and loader in case of cache using. I have to share content, not the instance. Am I right understand?)

@andrewbranch andrewbranch mentioned this issue Nov 19, 2019
9 of 16 tasks complete
@jpreynat

This comment has been minimized.

Copy link

@jpreynat jpreynat commented Nov 20, 2019

@sokra
Following the suggestions of @evilebottnawi, I'm currently switching our use of file-loader to the new type: 'asset' experiment introduced in alpha.19.

However, I am now seeing lots of warning regarding caching of our assets, like this one:

<w> [webpack.cache.PackFileCacheStrategy] Caching failed for /fonts/OpenSans.woff: TypeError: Cannot read property 'mappings' of null
<w> We will try to cache this entry again once in a while or when the cache file is deleted.

Is it something that will be fixed in the future or require any action on my part?
Thanks in advance.

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 20, 2019

@jpreynat I assume this fixes it: webpack/webpack-sources#78

@jpreynat

This comment has been minimized.

Copy link

@jpreynat jpreynat commented Nov 20, 2019

@sokra
Great, thanks.
I will test it once released and let you know.

@thasmo

This comment has been minimized.

Copy link

@thasmo thasmo commented Nov 20, 2019

@sokra, will webpack/webpack-sources#78 remove those messages in general? I'm seeing lots of those messages on cold cache.

Also, do I have to add the webpack config file manually to the cache dependencies when using the filesystem cache or is it added by webpack by default?

FYI: So far, it seems that the file cache is cutting (successive) production builds from 20s 11s to 5s in my case. 馃憤

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 20, 2019

Also, do I have to add the webpack config file manually to the cache dependencies when using the filesystem cache or is it added by webpack by default?

Currently yes, in future the CLI should automatically add it.

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 20, 2019

v5.0.0-beta.7

  • @AlonMiz fixes the webpackChunkName issue
  • @jpreynat should fix the mappings of null warning (and preformance regression)
@aaarichter

This comment has been minimized.

Copy link

@aaarichter aaarichter commented Nov 21, 2019

https://github.com/DanielSchaffer/webpack-babel-multi-target-plugin fails in v5.0.0-beta7 due to reference to missing internal files

  • Error: Cannot find module 'webpack/lib/MultiModuleFactory'
  • Error: Cannot find module 'webpack/lib/dependencies/SingleEntryDependency'
@aaarichter

This comment has been minimized.

Copy link

@aaarichter aaarichter commented Nov 21, 2019

the mini-css-extract-plugin https://github.com/webpack-contrib/mini-css-extract-plugin seems to have the following issue:

猬 webpack: Module build failed (from node_modules/mini-css-extract-plugin/dist/loader.js):
TypeError: The 'compilation' argument must be an instance of Compilation
    at Function.getCompilationHooks (/node_modules/webpack/lib/javascript/JavascriptModulesPlugin.js:115:10)
    at compiler.hooks.thisCompilation.tap.compilation (node_modules/webpack/lib/node/NodeTemplatePlugin.js:33:42)
    at Hook.eval (<anonymous>:7:1)
    at Hook.CALL_DELEGATE [as _call] (node_modules/webpack/node_modules/tapable/lib/Hook.js:14:14)
    at Compiler.newCompilation (node_modules/webpack/lib/Compiler.js:857:30)
    at hooks.beforeCompile.callAsync.err (node_modules/webpack/lib/Compiler.js:898:29)
    at Hook.eval [as callAsync] (<anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (node_modules/webpack/node_modules/tapable/lib/Hook.js:18:14)
    at Compiler.compile (node_modules/webpack/lib/Compiler.js:893:28)
    at Compiler.runAsChild (node_modules/webpack/lib/Compiler.js:436:8)
    at Object.pitch (node_modules/mini-css-extract-plugin/dist/loader.js:129:17)
@AlonMiz

This comment has been minimized.

Copy link

@AlonMiz AlonMiz commented Nov 21, 2019

@sokra regarding the persistent caching,
it would be great to know when and why the cache is invalidated. meaning that the cli will output the changed files that cause that to be invalidated.
[cache] starting a new cache due to a change in root/package.json
or
[cache] starting a new cache due to a version change
[cache] loading an existing cache [name=x] 100MB
etc.
https://github.com/mzgoddard/hard-source-webpack-plugin made it fine but had some critical bugs regarding the cache mechanism.

@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 21, 2019

@AlonMiz You can enable verbose logging with: infrastructureLogging: { level: "verbose" }. The default is silent and "just works".

@AlonMiz

This comment has been minimized.

Copy link

@AlonMiz AlonMiz commented Nov 21, 2019

@sokra getting this error when adding any config under infrastructureLogging
using webpack-dev-server of course...

鉁 锝ds锝: Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration.cache.type should be "memory".
   -> In memory caching
@sokra

This comment has been minimized.

Copy link
Member Author

@sokra sokra commented Nov 21, 2019

Not config.cache.infrastructureLogging but config.infrastructureLogging

@evilebottnawi

This comment has been minimized.

Copy link
Member

@evilebottnawi evilebottnawi commented Nov 21, 2019

@AlonMiz this error not related to webpack-dev-server, you have invalid configuration

@minimit

This comment has been minimized.

Copy link

@minimit minimit commented Nov 21, 2019

Thanks for the good works, as I said #10015 when using multiple alias

  resolve: {
    unsafeCache: false,
    alias: {
      'customFolder': [
        path.resolve(__dirname, './dist/customFolder'),
        path.resolve(__dirname, './node_modules/customFolder')
      ],
    },
  },

During watch if you add ./dist/customFolder/test.css the recompile doesn't trigger when ./node_modules/customFolder/test.css already was compiled, it should trigger because the first alias has precendence.

The behaviour when removing ./dist/customFolder/test.css is good instead, it triggers the recompile to ./node_modules/customFolder/test.css.

@jpreynat

This comment has been minimized.

Copy link

@jpreynat jpreynat commented Nov 21, 2019

@sokra beta.7 fixed it indeed. Thanks 馃憤

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can鈥檛 perform that action at this time.