"You forgot to add 'mini-css-extract-plugin' plugin" #167
Comments
|
this same issues. |
|
Same here |
|
+1 |
|
same issue |
|
+1 |
|
support webpack 5 ? |
|
any update on this? |
|
Same question |
|
+1 |
|
any updates there? |
|
+1 |
|
any solution? |
|
+1 |
3 similar comments
|
+1 |
|
+1 |
|
+1 |
|
Still happening with 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 similar comment
|
+1 |
|
I just downgraded mini-css-extract-plugin version to 1.3.6 |
|
Not work with SpeedMeasurePlugin. |
|
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 |
|
For those already using 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 = configToExportDidn'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? |
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 |
感谢，我使用上面高赞的重新push方法后报错，显示“MiniCssExtractPlugin”已经注册。于是用您的替代法成功了，太棒了！ |
|
"mini-css-extract-plugin": "^1.3.6", can success build |
|
Probably related: this also breaks https://github.com/jantimon/favicons-webpack-plugin : the |
|
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 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; // falseThe reference is not equal now, it's natural, right? However, this is a really bad news, because 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 |
|
I have this error related to to mini-css when I use this plugin 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 |
|
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 |
|
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 |
|
same |
|
the same |
@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:
|
|
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:
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 |
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. |
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? |
and others
Webpack 5 fails as soon as I
smp.wrap()my config, with the following error:The error stems from a missing symbol, which is defined when the plugin module loads, and assigned in a
compilationhook:However, with
smp.wrap()the inner callback above is never run and the symbol is never added to the loader's context.Cheers. :)
Versions
Config
The text was updated successfully, but these errors were encountered: