"You forgot to add 'mini-css-extract-plugin' plugin"
jalovatt opened this issue ยท 92 comments
Webpack 5 fails as soon as I smp.wrap()
my config, with the following error:
ERROR in ..../Error.scss
Module build failed (from ../../node_modules/mini-css-extract-plugin/dist/loader.js):
Error: You forgot to add 'mini-css-extract-plugin' plugin (i.e. `{ plugins: [new MiniCssExtractPlugin()] }`), please read https://github.com/webpack-contrib/mini-css-extract-plugin#getting-started
at Object.pitch (.../node_modules/mini-css-extract-plugin/dist/loader.js:50:14)
The error stems from a missing symbol, which is defined when the plugin module loads, and assigned in a compilation
hook:
// mini-css-extract-plugin/dist/loader.js@50
if (!this[_index.pluginSymbol]) {
callback(new Error("You forgot to add 'mini-css-extract-plugin' plugin (i.e. `{ plugins: [new MiniCssExtractPlugin()] }`), please read https://github.com/webpack-contrib/mini-css-extract-plugin#getting-started"));
return;
}
// mini-css-extract-plugin/index.js@362
compiler.hooks.compilation.tap(pluginName, compilation => {
const normalModuleHook = typeof NormalModule.getCompilationHooks !== 'undefined' ? NormalModule.getCompilationHooks(compilation).loader : compilation.hooks.normalModuleLoader;
normalModuleHook.tap(pluginName, loaderContext => {
// eslint-disable-next-line no-param-reassign
loaderContext[pluginSymbol] = true;
});
});
However, with smp.wrap()
the inner callback above is never run and the symbol is never added to the loader's context.
Cheers. :)
Versions
webpack: 5.21.0
mini-css-extract-plugin: 1.3.9
speed-measure-webpack-plugin: 1.5.0
Config
plugins: [
...
MiniCssExtractPlugin {
_sortedModulesCache: WeakMap { <items unknown> },
options: {
filename: [Function: filename],
ignoreOrder: false,
chunkFilename: 'chunk-[name].[contenthash].css'
},
runtimeOptions: {
insert: undefined,
linkType: 'text/css',
attributes: undefined
}
},
...
SpeedMeasurePlugin {
options: {},
timeEventData: {},
smpPluginAdded: true,
wrap: [Function: bound wrap],
getOutput: [Function: bound getOutput],
addTimeEvent: [Function: bound addTimeEvent],
apply: [Function: bound apply],
provideLoaderTiming: [Function: bound provideLoaderTiming],
generateLoadersBuildComparison: [Function: bound generateLoadersBuildComparison]
}
],
module: {
rules: [
...
{
test: /\.css$/,
include: /node_modules/,
use: [
'.../node_modules/mini-css-extract-plugin/dist/loader.js',
'.../node_modules/css-loader/dist/cjs.js'
]
},
{
test: /\.(sass|scss|css)$/,
exclude: /node_modules/,
use: [
'.../node_modules/mini-css-extract-plugin/dist/loader.js',
{
loader: '.../node_modules/css-loader/dist/cjs.js',
options: { importLoaders: 1 }
},
{
loader: '.../node_modules/sass-loader/dist/cjs.js',
options: {
implementation: {
run_: [Function],
render: [Function],
renderSync: [Function],
info: 'dart-sass\t1.23.0\t(Sass Compiler)\t[Dart]\n' +
'dart2js\t2.5.1\t(Dart Compiler)\t[Dart]',
types: [Object]
},
sassOptions: { fiber: false }
}
}
]
}
]
}
this same issues.
Same here
+1
same issue
+1
support webpack 5 ?
any update on this?
Same question
+1
any updates there?
+1
+1
+1
any solution?
+1
+1
+1
+1
Still happening with
"webpack": "5.38.1",
"mini-css-extract-plugin": "1.6.0",
I have the feeling this is an issue with the 'mini-css-extract-plugin' as this happens even without the 'speed-measure-webpack-plugin' installed.
+1
+1
I just downgraded mini-css-extract-plugin version to 1.3.6
https://github.com/webpack-contrib/mini-css-extract-plugin/releases/tag/v1.3.7
1.3.7 version cause this error.
Not work with SpeedMeasurePlugin.
I was deleted SpeedMeasurePlugin from my config and mini-css-extract-plugin work's fine
"dependencies": {
"format-money-js": "^1.4.3",
"selectivity": "^3.1.0",
"spectre.css": "^0.5.9",
"zepto-webpack": "^1.2.1"
},
"devDependencies": {
"case-sensitive-paths-webpack-plugin": "^2.4.0",
"circular-dependency-plugin": "^5.2.2",
"css-loader": "^5.2.6",
"expose-loader": "^3.0.0",
"imports-loader": "^3.0.0",
"inspectpack": "^4.7.1",
"mini-css-extract-plugin": "^1.6.1",
"node-sass": "^6.0.0",
"purecss-sass": "^2.0.5",
"sass-loader": "^11.1.1",
"speed-measure-webpack-plugin": "^1.5.0",
"style-loader": "^2.0.0",
"unused-files-webpack-plugin": "^3.4.0",
"webpack": "^5.37.1",
"webpack-cli": "^4.7.0"
}```
same issue
same issue, apart from lowering the version of mini-css-extract-plugin to 1.3.6, or remove smp.wrap(),
is there no other better solution that make smp and mini-css-extract-plugin use the latest version at the same time?
same issue
+1
+1
I spent a little bit of time trying to debug this but haven't come up with anything conclusive. Here's some notes:
This plugin appears to produce a relevant deprecation warning:
(node:63005) [DEP_WEBPACK_COMPILATION_NORMAL_MODULE_LOADER_HOOK] DeprecationWarning: Compilation.hooks.normalModuleLoader was moved to NormalModule.getCompilationHooks(compilation).loader
mini-css-extract-plugin
throws the "You forgot to add..." error if it can't find Symbol(mini-css-extract-plugin)
symbol in the loader context
This is set on the NormalModule
compilation hook:
Disabling wrapping for Compiler
"fixes" the issue
const construcNamesToWrap = [
// "Compiler",
"Compilation",
"MainTemplate",
"Parser",
"NormalModuleFactory",
"ContextModuleFactory",
];
This hook never gets called when SMP is wrapping Compiler
, so loaderContext[pluginSymbol]
is never being set
That's about as far as I got, hopefully this is useful. I'm pretty unfamiliar with webpack internals so most of this is new to me so maybe somebody more familiar will be able to fix it from here.
+1
+1
+1
Still happening with
"webpack": "5.38.1", "mini-css-extract-plugin": "1.6.0",
I have the feeling this is an issue with the 'mini-css-extract-plugin' as this happens even without the 'speed-measure-webpack-plugin' installed.
No, I resolved the problem without the 'speed-measure-webpack-plugin'!!!
(node:4422) [DEP_WEBPACK_COMPILATION_NORMAL_MODULE_LOADER_HOOK] DeprecationWarning: Compilation.hooks.normalModuleLoader was moved to NormalModule.getCompilationHooks(compilation).loader at getNormalModuleLoader (node_modules/webpack/lib/Compilation.js:408:39) at Object.get normalModuleLoader [as normalModuleLoader] (node_modules/webpack/lib/Compilation.js:841:12) at genProxy (node_modules/speed-measure-webpack-plugin/WrappedPlugin/index.js:124:34) at node_modules/speed-measure-webpack-plugin/WrappedPlugin/index.js:152:19 at Array.reduce (<anonymous>) at wrapHooks (node_modules/speed-measure-webpack-plugin/WrappedPlugin/index.js:151:38) at Object.get (node_modules/speed-measure-webpack-plugin/WrappedPlugin/index.js:221:18) at Proxy.<anonymous> (node_modules/ignore-emit-webpack-plugin/index.js:64:33) at node_modules/speed-measure-webpack-plugin/WrappedPlugin/index.js:52:19 at Hook.eval [as call] (eval at create (node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:19:10), <anonymous>:98:1)
So, this plugin not working (with .wrap)?
+1
+1
+1
Is there any workaround to resolve this issue? mini-css-extract-plugin is now 2.3.0 and still this issue came up when we use this plugin. ๐ข
+1
+1
+1
@wuliqiangqiang @Liaozzzzzz @KingOfCramers @PenguinShade @MaksZhukov @RichardZhang12 shame on you guys. You show your disrespect to the open source space in a very bad way. I don't want any shameless message from you just because I'm interested in meaningful messages on this topic. What do you expect with "+1"? Please, stop doing crap. Instead you can just vote on the first comment or better provide a pull request to fix this issue.
I solved this problem by Downgrade min-css-extract-plugin to 1.3.6
Still an issue. Changing the version did not solve the issue for me.
@+1
min-css-extract-plugin and vue-loader error
+1
+1
Still happening with
"webpack": "^5.63.0",
"mini-css-extract-plugin": "^2.4.4",
Any indication as to when this might be resolved? or any work arounds? the issue still persists
Still happening with
"webpack": "^5.64.1",
"mini-css-extract-plugin": "^2.4.5",
"speed-measure-webpack-plugin": "^1.5.0",
As a hacky workaround, you can append MiniCssExtractPlugin
after wrapping with speed-measure-webpack-plugin
:
// webpack.config.js
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const config = {
// ...
plugins: [
// Whatever other plugins you may have
]
};
const configWithTimeMeasures = new SpeedMeasurePlugin().wrap(config);
configWithTimeMeasures.plugins.push(new MiniCssExtractPlugin({}));
module.exports = configWithTimeMeasures;
As a hacky workaround, you can append
MiniCssExtractPlugin
after wrapping withspeed-measure-webpack-plugin
:// webpack.config.js const SpeedMeasurePlugin = require('speed-measure-webpack-plugin'); const MiniCssExtractPlugin = require('mini-css-extract-plugin'); const config = { // ... plugins: [ // Whatever other plugins you may have ] }; const configWithTimeMeasures = new SpeedMeasurePlugin().wrap(config); configWithTimeMeasures.plugins.push(new MiniCssExtractPlugin({})); module.exports = configWithTimeMeasures;
I did same with AngularWebpackPlugin too to make it work in @nrwl/nx repo
`module.exports = (config) => {
const miniCssExtractPluginOrig = config.plugins.find((plugin) => plugin instanceof MiniCssExtractPlugin);
const angularWebpackPluginOrig = config.plugins.find((plugin) => plugin instanceof AngularWebpackPlugin);
config.plugins = config.plugins.filter((plugin) => !(plugin instanceof MiniCssExtractPlugin));
config.plugins = config.plugins.filter((plugin) => !(plugin instanceof AngularWebpackPlugin));
const smp = new SpeedMeasurePlugin();
const newConfig = smp.wrap({
...config,
});
newConfig.plugins.push(miniCssExtractPluginOrig);
newConfig.plugins.push(angularWebpackPluginOrig);
return newConfig;
};`
As a hacky workaround, you can append
MiniCssExtractPlugin
after wrapping withspeed-measure-webpack-plugin
:// webpack.config.js const SpeedMeasurePlugin = require('speed-measure-webpack-plugin'); const MiniCssExtractPlugin = require('mini-css-extract-plugin'); const config = { // ... plugins: [ // Whatever other plugins you may have ] }; const configWithTimeMeasures = new SpeedMeasurePlugin().wrap(config); configWithTimeMeasures.plugins.push(new MiniCssExtractPlugin({})); module.exports = configWithTimeMeasures;
Thanks for share
I'm getting the same issue when attempting to use MiniCssExtractPlugin
in my customWebpackConfig
, using the Angular custom-webpack
builder.
As far as I can see, it isn't using the SpeedMeasurePlugin()
, but I'm guessing that Angular CLI must be doing something similar to the config, which is similarly interfering with this plugin?
+1
Does the new version solve this problem?
@JuctTr nops, still the same issue, "mini-css-extract-plugin": "2.6.0"
I made it,Using this method;
But the AddAssetHtmlPlugin plugin loses its effect
same problem.
the same problem.
+1
+1
I had this problem on a Windows server in PhpStorm terminal, and when I launched my command in the default Windows cmd it worked. I don't know if it can help someone. It's probably a problem from JetBrains apps (?) I guess not for everyone, but well...
For those already using MiniCssExtractPlugin
but can't use the workaround above because you'll get it twice in your plugins list, a workaround can be to extract your plugin definition before, then put it back after the wrapping:
const cssPluginIndex = webpackConfig.plugins.findIndex(
(e) => e.constructor.name === "MiniCssExtractPlugin"
)
const cssPlugin = webpackConfig.plugins[cssPluginIndex]
const configToExport = smp.wrap(webpackConfig)
configToExport.plugins[cssPluginIndex] = cssPlugin
module.exports = configToExport
Didn't get the issue anymore after that and the css build is still measured ๐
@CPatchane - this worked for me as well. Thanks for the snippet!
Hi guys, I am writing a successor of this plugin: https://github.com/ShuiRuTian/time-analytics-webpack-plugin.
You could have a try with it. I believe it's providing a better experience for webpack 5.
And I believe it also resolve this strange issue, no more strange hacks.
It's in an early period(the API is not frozen and maybe buggy), but it's working for me.
Any feedback is welcomed!
At this point, this issue seriously needs to be fixed. It's one of the most popular CSS plugins, and the fact that almost two years after the issue of this problem existing, this hasn't been fixed? Is this not being maintained anymore?
At this point, this issue seriously needs to be fixed. It's one of the most popular CSS plugins, and the fact that almost two years after the issue of this problem existing, this hasn't been fixed? Is this not being maintained anymore?
First of all, why do you think giving @ShuiRuTian a thumbs down for trying to solve this on their own is helpful? And secondly, the person who maintains this repo is likely doing this on their own time, not getting paid for this, and this has a workaround. Many maintainers have stopped sharing their work altogether when demanding people harass them about problems but are unwilling to help out. If this is so important to you, open a PR.
Remove MiniCssExtractPlugin.loader in loader
ๅฏนไบ้ฃไบๅทฒ็ปๅจไฝฟ็จไฝๆ ๆณไฝฟ็จไธ่ฟฐ่งฃๅณๆนๆณ็ไบบ๏ผๅ ไธบๆจๅฐๅจๆไปถๅ่กจไธญ่ทๅพไธคๆฌก๏ผ่งฃๅณๆนๆณๅฏไปฅๆฏๅจไนๅๆๅๆไปถๅฎไน๏ผ็ถๅๅจๅ ่ฃ ๅๅฐๅ ถๆพๅ๏ผ
MiniCssExtractPlugin
const cssPluginIndex = webpackConfig.plugins.findIndex( (e) => e.constructor.name === "MiniCssExtractPlugin" ) const cssPlugin = webpackConfig.plugins[cssPluginIndex] const configToExport = smp.wrap(webpackConfig) configToExport.plugins[cssPluginIndex] = cssPlugin module.exports = configToExportๅจ้ฃไนๅๅฐฑๆฒกๆๅ้ๅฐ่ฟไธช้ฎ้ขไบ๏ผๅนถไธไป็ถๆต้ไบcssๆๅปบ๐
ๆ่ฐข๏ผๆไฝฟ็จไธ้ข้ซ่ต็้ๆฐpushๆนๆณๅๆฅ้๏ผๆพ็คบโMiniCssExtractPluginโๅทฒ็ปๆณจๅใไบๆฏ็จๆจ็ๆฟไปฃๆณๆๅไบ๏ผๅคชๆฃไบ๏ผ
Thanks, I reported an error after using the repush method with the highest number of likes above, saying that "MiniCssExtractPlugin" is already registered. So I switched to your alternative and succeeded, great!
"mini-css-extract-plugin": "^1.3.6",
"webpack": "^5.21.1",
can success build
Probably related: this also breaks https://github.com/jantimon/favicons-webpack-plugin : the alterAssetTags
hook isn't called when HtmlWebpackPlugin is wrapped.
I still suggest to try this package https://github.com/ShuiRuTian/time-analytics-webpack-plugin (written by me :p)
speed-measure-webpack-plugin is awesome, however, it's almost dead and not got updated for about 2 years.
And for now, it might cause perf issue and introduce subtle bugs, which should all be resolved("hacked" is more proper) in my new package.
If you are interested in the details, here we go.
Fact 1: Webpack and plugins use a lot of WeakMap
internally as cache or state store.
Fact 2: to measure the time, we need to proxy the methods, so that we could record the start/end time and do some other stuffs. Not so surprised, speed-measure-webpack-plugin chooses Proxy
to do this.
However, this introduces a subtle issue
// `foo` is an object, the content is not important for us.
const foo = {};
// `proxyFoo` is a proxy,the second parameter is pretty powerful, but we also not care it here.
const proxyFoo = new Proxy(foo,{});
proxyFoo === foo; // false
The reference is not equal now, it's natural, right?
However, this is a really bad news, because foo
stands for the thing which would used as the key of WeakMap
.
If the WeakMap is used as cache, we need to calculate the value again for each plugin(because it creates proxy for each ). And if the proxy object is not cached, we will always need to calculate the value, because the proxy object will always be a differnet one. In this situation, it would make whole thing slower.
If the WeakMap is used as a state store, then everything might be wrong. In this situation, it might cause subtle bug.
module.exports = function (env) {
const isProduction = env.production
const tempConfig = isProduction ? productionConfig : developmentConfig
const configWithTimeMeasures = new SpeedMeasurePlugin().wrap(merge(commonConfig(isProduction), tempConfig));
configWithTimeMeasures.plugins.push(new MiniCssExtractPlugin({
filename: "css/[name].css",
chunkFilename: "css/[name]_chunk.css",
}));
return configWithTimeMeasures
}
Provious cgs are exported as a function
Like these,it works successfully!
I have this error related to to mini-css when I use this plugin
TypeError: Cannot read properties of undefined (reading 'serialization')
at MiniCssExtractPlugin.apply (/Users/pepito-perez/getaround/getaround-web/node_modules/mini-css-extract-plugin/dist/index.js:641:20)
at WrappedPlugin.apply (/Users/pepito-perez/getaround/getaround-web/node_modules/speed-measure-webpack5-plugin/WrappedPlugin/index.js:290:29)
at createCompiler (/Users/pepito-perez/getaround/getaround-web/node_modules/webpack/lib/webpack.js:73:12)
at create (/Users/pepito-perez/getaround/getaround-web/node_modules/webpack/lib/webpack.js:134:16)
at webpack (/Users/pepito-perez/getaround/getaround-web/node_modules/webpack/lib/webpack.js:158:32)
at WebpackCLI.f [as webpack] (/Users/pepito-perez/getaround/getaround-web/node_modules/webpack/lib/index.js:64:16)
at WebpackCLI.createCompiler (/Users/pepito-perez/getaround/getaround-web/node_modules/webpack-cli/lib/webpack-cli.js:1789:29)
at async Command.<anonymous> (/Users/pepito-perez/getaround/getaround-web/node_modules/@webpack-cli/serve/lib/index.js:105:30)
at async Promise.all (index 1)
at async Command.<anonymous> (/Users/pepito-perez/getaround/getaround-web/node_modules/webpack-cli/lib/webpack-cli.js:1372:13)
any idea, workaround?
I end doing this:
const speedMeasure = (config) => {
const searchPlugin = (name) =>
config.plugins.findIndex((e) => e.constructor.name === name)
const reactRefreshPluginIndex = searchPlugin("ReactRefreshPlugin")
const cssPluginIndex = searchPlugin("MiniCssExtractPlugin")
const cssPlugin = config.plugins[cssPluginIndex]
const reactRefreshPlugin = config.plugins[reactRefreshPluginIndex]
const configToExport = smp.wrap(config)
configToExport.plugins[cssPluginIndex] = cssPlugin
if (reactRefreshPluginIndex !== -1)
configToExport.plugins[reactRefreshPluginIndex] = reactRefreshPlugin
return configToExport;
}
return isProfiling ? speedMeasure(config) : config;
It seems that in NormalModule
of the webpack, the hooks of Compilation
instance are maintained by the WeakMap.get(compilation)
call, the SMP plugin replaced the compilation object with a proxy for all other plugins, so the static call NormalModule.getCompilationHooks
for plugins always returns wrong hooks. This PR seems have resolved the problem. I'll try it.
well, after inspecting the issues, they are just incompatible because MiniCssExtractPlugin just pass configs between loader and plugin by the compiler object, which is replaced by a compiler object in this plugin. So I just use new webpack.ProgressPlugin({ profile: true })
instead.
Like this
config => {
const searchPlugin = name =>
config.plugins.findIndex(p => p.constructor.name === name)
const omitPlugin = index => config.plugins.splice(index, 1)[0]
const omitPlugins = plugins => {
plugins = plugins.reduce((result, name) => {
const index = searchPlugin(name)
if (index >= 0) {
result.push({ index, plugin: omitPlugin(index) })
}
return result
}, [])
return () => {
plugins.forEach(({ index, plugin }) => {
config.plugins.splice(index, 0, plugin)
})
}
}
const restorePlugin = omitPlugins(['Plugin1', 'Plugin2'])
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin')
new SpeedMeasurePlugin().wrap(config)
restorePlugin()
return config
}
I got same issue, and as it was saying to read the guidline here, then i follow it by installing using the command pnpm add -D mini-css-extract-plugin
, then the problem is gone.
same
the same
kMap is used as cache, we need to calculate the value again for each plugin(because it creates proxy for each ). And if the proxy object is not cached, we will always n
@ShuiRuTian I tried your alternative plugin. It's quite good and no bugs. However it seems really inaccurate and confusing. There are multiple things with time results. Does it mean they are all running in parallel? Or there is some issue with the time keeping? My results:
โโโ time-analytics-webpack-plugin
โ Webpack compile takes 120710.3568 ms
โโโ Plugins
โ Plugin TerserPlugin takes 20769.5217 ms
โ Plugin ESLintWebpackPlugin takes 2779.2995 ms
โ Plugin CssMinimizerPlugin takes 1555.3495 ms
โ Plugin HtmlWebpackPlugin takes 171.7745 ms
โ Plugin WebpackManifestPlugin takes 26.3319 ms
โ Plugin MiniCssExtractPlugin takes 7.8416 ms
โ Plugin DefinePlugin takes 3.4362 ms
โ Plugin ForkTsCheckerWebpackPlugin takes 0.9461 ms
โ Plugin InlineChunkHtmlPlugin takes 0.4624 ms
โ Plugin ModuleNotFoundPlugin takes 0.1330 ms
โ Plugin InterpolateHtmlPlugin takes 0.0762 ms
โ All plugins take 25315.1726 ms
โโโ Loaders
โ Loader babel-loader takes 2147845.5583 ms
โ Loader source-map-loader takes 180303.8255 ms
โ Loader mini-css-extract-plugin takes 116059.0275 ms
โ Loader @svgr/webpack takes 38772.6433 ms
โ Loader postcss-loader takes 452.6405 ms
โ Loader css-loader takes 5.7927 ms
โ Loader file-loader takes 5.6811 ms
โ All loaders take 2483445.1689 ms
Hi @goamn , thanks for using it.
The alternative plugin records the 2 time points, the starting and ending of a loader function. In fact, there would be a thrown error if the plugin does not receive paired time points of a loader execution. So, we could say we always receive the time points we want.
As you said, the time are "inaccurate and confusing", it looks like so at the first glance. It might be indeed a bug. But, it might be surprisingly easy to do things in parallel in JS, many thanks to event-loop.
Here is an example for an async loader:
- At time point T1, a loader is started and we record the time.
- The loader wants to read file, so it creates a promise P1, and gives the control back to webpack.
- Webpack runs some loader(maybe same, not important) for another file, also, we record the starting time point T2.
- The second loader also wants to read a file, creates promise.
- We assume there is no more work, so the event loop enters idle status
- P1 and P2 are all resolved after a long time.
- The first loader does the remaining work and ends at time point T3.
- Similarly, the second loader ends at time point T4.
The time is almost duplicated for twice here.
And babel-loader is indeed an async-loader, I think it's what happened here.
Do you have any suggestions on this? I know there are some hooks might be helpful: https://nodejs.org/api/async_context.html and https://nodejs.org/api/async_hooks.html. But they are Experimental
, which is suggested to be avoided.
type Flatten<Type> = Type extends Array<infer Item> ? Item : Type;
type IndexedPlugin = { index: number; plugin: Flatten<webpack.Configuration["plugins"]> };
const omitPlugins = (configuration: webpack.Configuration, ...names: string[]): IndexedPlugin[] => {
const { plugins } = configuration;
if (!plugins) throw new Error("Plugins are not defined.");
const extracted = plugins
.map((plugin, index) => (names.includes(plugin?.constructor.name ?? "<skip>") ? { index, plugin } : null))
.filter(Boolean) as IndexedPlugin[];
return extracted ?? [];
};
const recoverPlugins = (configuration: webpack.Configuration, ...plugins: IndexedPlugin[]) => {
const { plugins: originalPlugins } = configuration;
if (!originalPlugins) throw new Error("Plugins are not defined.");
plugins.forEach(({ index, plugin }) => {
originalPlugins[index] = plugin;
});
};
const withSmpMeasuring = (configuration: webpack.Configuration) => {
// FIXME (olku): this is a hack/workaround to get the SMP plugin work.
// ref: https://github.com/stephencookdev/speed-measure-webpack-plugin/issues/167
const excludes = omitPlugins(configuration, "MiniCssExtractPlugin");
const smp = new SpeedMeasurePlugin({ disable: !process.env.MEASURE });
const withSmpMeasuring = smp.wrap(configuration);
recoverPlugins(withSmpMeasuring, ...excludes);
return withSmpMeasuring;
};
// usage
return withSmpMeasuring(webpackConfiguration);
anyone can resolved it?
As explained above, you can wrap as a workaround but it's not perfect. This project is dead, stop using it.
Maybe try Rsdoctor? It is a tool for build analysis made by the Rspack team, and supports both Webpack 5 and Rspack.
Maybe try Rsdoctor? It is a tool for build analysis made by the Rspack team, and supports both Webpack 5 and Rspack.
yes, it can help to analyze the build
Even i am not using webpack , still getting this error, does anyone know or have this issue?