No module factory available for dependency type: CssDependency #493
Comments
|
Also having this issue and am really blocked by it.
Similar/same errors that may provide cluesangular/angular-cli#9680 |
|
@morewry thanks for linking to the other issues. It helped me find this thread before SEO could find this issue. |
|
You're welcome! I can see this in the Which, I dunno what any of this internal Webpack stuff is, but that looks an awful lot like this from the plugin implementation. compilation.dependencyFactories.set(
CssDependency,
new CssModuleFactory()
);Relevant config portions as logged: Plugin and loader are definitely from the same installed package, version If I comment out all The actual error stack: Also sort of what I'd expect, though again I don't know about this internal Webpack stuff: It seemed to overcome this for two builds in a row last night, but after I did a clean install to address another error about being unable to find one of the CSS files in question it went back to this. The only unusual things here are:
Note this was working in late November/early December, before I had to put the project down for a few weeks. |
|
Oooh, I tried disabling |
|
Thanks for the additional info of what you tested (pretty much all the same URLs as I'd visited). Unfortunately disabling |
|
I'd manually enabled that, so unless you have it's an unlikely fix, but it does mean I was getting the error due to file paths. I don't know why the paths matter here when it's ultimately the same exact file, but, it's something. |
|
Could be related to #489 |
|
Just wonder do you have error on 0.8.0? Same? |
|
looks like there is a some regression after some 0.8.x version, i think it is better to leave it open Glad that downgrading works for your case (doesn't work in mine) |
|
Downgrading didn't work for me. So +1 keep the issue open. |
|
We had a similar problem and in our case our custom build tool was assembling Webpack config out of two separate JS files. Both files were importing We fixed this by removing one instance of |
|
I had the same problem in my mistakes // project A webpack.config.js
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
// ...
module: {
rules: [{
test: /\.(css|scss)$/,
use: [{ loader: MiniCssExtractPlugin.loader },...]
}]
}
// ...
plugins: [new MiniCssExtractPlugin({...})]// project B webpack.config.js
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
// ...
module: {
rules: [{
test: /\.(css|less)$/,
use: [{ loader: MiniCssExtractPlugin.loader },...]
}]
}
// ...
plugins: [
// not new MiniCssExtractPlugin
]Usage: So two "mini-css-extract-plugin" are not the same code. But it is correct in |
|
I also have the same issue |
|
Same here |
1 similar comment
|
Same here |
|
+1 |
|
I'm having the same issue. |
|
I read somewhere this maybe because of multiple installations of |
|
I have only 1 instance of webpack installed but still getting the error. |
|
I had two issues in my source code;
Not sure if the first one was still an issue but good riddance! |
|
I only found success with v0.8.0 of mini-css-extract-plugin, when used with vue-cli-service (v0.9.0, v0.8.2, and v0.8.1 resulted in the same CssDependency error message). I pinned the version via the following package.json entry: |
|
Fixed this issue, I was missing plugin (see set plugins sections below) const MiniCssExtractPlugin = require('mini-css-extract-plugin');
//define module\rules
{
test:/\.css$/,
use:[{loader: MiniCssExtractPlugin.loader},{loader:'css-loader'}]
},
//set plugins
plugins:[
new vueLoaderPlugin(), new MiniCssExtractPlugin()
] |
|
Not sure if I'll have to use the plugin eventually. Reading through similar issues I tried running build command in powershell and it just worked. Guessing it resolves the casing properly. This issue for me is in using bash shell for windows which I would like to be able to continue using if anyone has a fix for that. |
|
I've been able so far, to have all of my apps use the same webpack rules, so I'm importing the same webpack.dev, webpack.prod, and webpack.common into all of my apps webpack.config.js files, so I was puzzled when only one of my apps broke with this error. I discovered that the apps were using different versions of both webpack and webpack-cli as I merely, at different times, did `yarn workspace <app_name> add webpack webpack-cli' without specifying versions. Anyway, I noticed that some of my apps (the ones which built properly) 'node_modules' subdir had more than just a '.bin' subdir, and in fact had webpack-cli/node_modules/**/node_modules including @WebAssembly and enhanced-node-resolver, etc. I'm sure these aren't the versions I should be using, but I just set everything to use: and now everything builds just fine, despite my still using 'mini-css-extract-plugin' "^0.9.0" I don't want to send anyone down a rabbit hole, but this worked for me |
|
If you use webpack-merge to merge the cooperation, MiniCssExtractPlugin is used in the loader, but the MiniCssExtractPlugin is not used in the same file as MiniCssExtractPlugin, the error will occur!!! You need to be in the same file Use MiniCssExtractPlugin in both the loader and plugin. like this: |
|
I believe that problem is not related to wrong configuration (see configs example in first post) |
|
I am seeing this error as well. Can't seem to get to the bottom of it although I do know that it is likely down to the way I am using the webpack configs. I have created a repository that is a replication of the setup I am using. Essentially I was trying to create a way where you could run Here is the repo: https://github.com/nfourtythree/webpack-mini-css-extract-plugin-error I have written instructions in the readme on how to reproduce the error. I hope this can help narrow down where the issue is coming from. From testing, it seems as soon as mini css extract rule is hit more than once it falls over. |
Not sure if it was more important that they all be the same version or that it's not 0.9. |
|
This bug happens only when you forgot to use plugin, unfortunately we can't fix it on our side, we already show it in our docs, but some developers still don't read them 😞 Anyway if you faced with this issue and you have loader and plugin feel free to feedback, I will help you |
|
Except that people reporting this issue, such as myself, are using the plugin. I've had this problem repeatedly while remembering to use the plugin. There is another issue, something very touchy in the package about the correspondence between the loader and plugin. |
|
@morewry can you create reproducible test repo? |
|
@evilebottnawi if you check my comment: #493 (comment) That has a repo you can check out and replicate the issue I am having |
|
@nfourtythree You reproducible test repo doesn't work: But i found you use |
|
Hmm strange, will take a look and make sure it shows the correct error. Your point about decache might be true but I have everything working and things only break when I update the mini css extract plugin. |
|
@evilebottnawi I have just tried this again and the repo does produce the error. Here is a screen recording for you to watch and below is a stack trace. As mentioned before I have it working in my project if I have |
|
@nfourtythree can you update reproducible test repo, because it doesn't work |
|
Did you watch the video I posted above that showed cloning, installing packages and building the test repo? That was a straight clone from the test repo, I don't know what you are doing differently for it not to work for you? Just to clarify these are my software versions |
|
@nfourtythree thanks, I will return to this in near future |
|
@nfourtythree you use global installed |
|
Still have error after I don't have your environment, |
|
Reproduced, remove
But you use it not for the My recommendation is not remove I would say even more - it is not safe. |
|
in my case, the error happened because the service worker entry point (indirectly) imports a CSS file. |
|
你好，你的邮件我已收到
|
|
I had the same issue , |
|
I was encountering this issue because I (unknowingly) had two versions of I was able to identify this by running Once Identified, I was able to resolve the issue by using the |
and others
Expected Behavior
To extract css as per usual
Actual Behavior
Gets to about 35% of webpack build and blows up with the following error:
https://gist.github.com/oldtinroof/241e618a5899e2a9c39cf13f29e91409
Code
Webpack config (relevant bits)
https://gist.github.com/oldtinroof/bae711f388e9df6212a46945c4036d0b
Babelrc (just in case it helps)
https://gist.github.com/oldtinroof/189e7333e2e2c0fc41f122019efb4853
How Do We Reproduce?
Not an easy one to reproduce to be honest (sorry!)
I'm in the process of updating a fairly old, rather massive project from Webpack 3 to 4.
It works fine in development mode through webpack-dev-server, and the webpack build runs fine when I remove mini-css-extract-plugin, but obviously then doesn't extract the css.
Each time the build fails, it's a different file in the
webpack/node_modules/babel-runtime/helpersfolder.Have tried:
But nothing so far gets me up and running...
The text was updated successfully, but these errors were encountered: