mini-css-extract-plugin: TypeError: Cannot read property 'split' of undefined
tried to use webpack-i18n-extractor-plugin together with mini-css-extract-plugin. The build fails with the following error:
C:\P\git\dojo-webpack-plugin-sample\node_modules\mini-css-extract-plugin\dist\index.js:81
const resource = this._identifier.split('!').pop();
^
TypeError: Cannot read property 'split' of undefined
at CssModule.nameForCondition (C:\P\git\dojo-webpack-plugin-sample\node_modules\mini-css-extract-plugin\dist\index.js:81:39)
at Function.checkTest (C:\P\git\dojo-webpack-plugin-sample\node_modules\webpack\lib\optimize\SplitChunksPlugin.js:304:52)
at Object.fn [as getCacheGroups] (C:\P\git\dojo-webpack-plugin-sample\node_modules\webpack\lib\optimize\SplitChunksPlugin.js:249:35)
at compilation.hooks.optimizeChunksAdvanced.tap.chunks (C:\P\git\dojo-webpack-plugin-sample\node_modules\webpack\lib\optimize\SplitChunksPlugin.js:504:38)
at SyncBailHook.eval [as call] (eval at create (C:\P\git\dojo-webpack-plugin-sample\node_modules\tapable\lib\HookCodeFactory.js:17:12), <anonymous>:7:16)
at SyncBailHook.lazyCompileHook [as _call] (C:\P\git\dojo-webpack-plugin-sample\node_modules\tapable\lib\Hook.js:35:21)
at Compilation.seal (C:\P\git\dojo-webpack-plugin-sample\node_modules\webpack\lib\Compilation.js:1196:38)
at hooks.make.callAsync.err (C:\P\git\dojo-webpack-plugin-sample\node_modules\webpack\lib\Compiler.js:547:17)
at _err0 (eval at create (C:\P\git\dojo-webpack-plugin-sample\node_modules\tapable\lib\HookCodeFactory.js:24:12), <anonymous>:11:1)
at _addModuleChain (C:\P\git\dojo-webpack-plugin-sample\node_modules\webpack\lib\Compilation.js:1053:12)
at processModuleDependencies.err (C:\P\git\dojo-webpack-plugin-sample\node_modules\webpack\lib\Compilation.js:979:9)
at _combinedTickCallback (internal/process/next_tick.js:131:7)
at process._tickCallback (internal/process/next_tick.js:180:9)
When I remove WebpackI18nExtractorPlugin from the configuration, the build finishes successfully.
The simple project demonstrating this issue can be found here.
NodeJS version is 8.11.2
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 8
- Comments: 43 (13 by maintainers)
@evilebottnawi yeah, css-loader@4 with mini-css-extract-plugin@1 and style-loader@2 works fine. Thank you!
I ran into this recently. I didn’t realize that
css-loaderhad to be used directly afterMiniCssExtractPlugin.loader. Maybe it would be helpful to document that? I know it is used in all the examples but I didn’t know it was required.Bump, still having this issue with no solution…
I was having the same issue, but ive found the solution. ive setup, a stack of loaders in the following order:
Before
MiniCssExtractPlugin.loader!clean-css-loader!css-loader!postcss-loader!resolve-url-loader!sass-loadernotice CleanCss Loader was between MiniCss, and css-loader, and this was causing the bug. i got it fixed when i placed it between css-loader and postcss-loader
After
MiniCssExtractPlugin.loader!css-loader!clean-css-loader!postcss-loader!resolve-url-loader!sass-loader@evilebottnawi here’s a test repo - https://github.com/hellatan/webpack-mini-css-bug
I’ve been digging around and it seems like it has to do with how webpack is compiling the assets from my observations. I’m also using css modules for my config.
Just for reference, then I mention
optionswithcss-loader, the configuration looks like this:When I mentions
css-loaderis a string, the configuration is the following:In the string configuration, you can even do this:
and it will act like the string option.
Now that that setup is out of the way, from what I can tell, the following is getting set to
undefinedin src/index.js#L33 because thedependencyargument isnullwhen theCssModuleclass is instantiated. Walking through the loader, this condition is what provides thenullargument: src/loader.js#L185. When you are passing inoptionstocss-loader, the output ends up being something like this:When
css-loaderis just a string, the output ends up looking something like this:By having the latter shape, this error is not thrown.
I was really trying to track this problem, but I’m really not familiar with how webpack internally handles module rule settings and loaders. I saw that output from src/loader.js#L122 is different when using the
optionsvsstringconfigurations.The
optionsconfiguration output something like this:The string configuration output something like this:
The most significant difference is that the string config has this
function(module, exports, __webpack_require__)AND one additional method compiled with it as apart of its output whereas theoptionsconfig looks more likefunction(module, exports). Maybe I’m grasping at straws at this point, so I’m not sure if this is of significance or not.Hopefully all of this info helps out as i’m stuck on css-loader@1.0.1 for the time being because I need to pass options into our css-loader. I think this issue even popped up when upgrading to css-loader@2.0.0.
I was having the same error, but had the order of loaders as described here. After much searching I found out that the culprit was the
exportOnlyLocals: trueoption incss-loader.This comes from the official documentation of
css-loader:@evilebottnawi sure
make a .env file at the root folder with this content :
Run production build with webpack (config/webpack/app.prod.ts) :
@darkangel081195 no i didn’t fixed it yet.
I’m also getting this error when using webpack 5. In the latest version 4 of webpack, everything was going nicely 😕 :
css-loader: 4.3.0 mini-css-extract-plugin: 1.0.0 webpack: 5.0.0
my rule :
Stack trace :
Repository to reproduce (branch refacto) : https://github.com/blephy/reactjs-typescript-pwa/tree/refacto
@ogonkov yep, I think about it, but it is hard to know what previously loader exports (when you use
exportOnlyLocalscss-loaderemits object with locals, but when you don’t use this optionscss-loaderemits array of css modules), also you can use any loader (even don’t usecss-loader), but I have idea, we will avoid create modules without identifierHere you go https://gist.github.com/ogonkov/d4060500cf3d5b8b78e61fac9b8befe9
css-loader@4.2.2
error didn’t happen when
exportOnlyLocalsisfalseAnyway errors shouldn’t happen this way. If config file is not met some conditions, it should throw some human readable error with error reason.
Check your
css-loaderversion - you can get this error ifcss-loadermore than3.2.0Have anyone try extract-css-chunks-webpack-plugin instead? I tried and it worked in my case as I need to extract CSS from js bundle which used
css-modulesunder the hood. I do not have SSR in case you wonder but I do generating bundle for browser use +css-modulessoonlyLocalswould not work quite well in my case as I use Node. Don’t know if it is gonna work for your case but it is worth a try though.FYI, there was a related issue in webpack-i18n-extractor-plugin repository. It was fixed by the author. You can read the explanation of the fix there.