-
Notifications
You must be signed in to change notification settings - Fork 59
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
css-loader 6.4.0 breaks astroturf #728
Comments
Looks like there isn't really anything i can do until the team adds an alternative, which they've said they are working on. I would pin the css-loader version below 6.4.0 until then. Or use the older loader option (and lose persistent cache as well) |
err maybe if the locals convention was configured to use content hash that would work? |
@jquense yep, I've already done so. I'm following along on the css-loader issue |
Sorry, I just noticed this. Could you elaborate? Is [contenthash] available for localIdentName? |
it seems like it? I didn't think so but the webpack thread suggested it was |
Hey, just wondering if any changes were planned around this. We're currently working around it by pinning [email protected], needed due to combination of webpack 5 and astroturf+useAltLoader (we've had trouble making the non-alt loader work in dev with webpack 5's caching). Would be happy to try and help if there's anything that can be done. I unfortunately don't have enough experience with astroturf to understand much of this thread. Really appreciate the library in general, it's a great tool. |
I don't think there is anything i can do to fix this without help from the webpack team. If you want to chime in on the webpack issue it might help. I'm happy to do whatever, but currently they left us broken with no real alternative :/ |
Thanks for the reply, I asked over there. Will try and build some personal understanding of the issue so perhaps I can be of more help. |
We were having an issue that I think is related to this and I wanted to document it here in case this helps anyone that stumbles in here like I did. Our CSS-in-JS was being built correctly on the first build and would rebuild correctly once, if a change was made in the CSS-in-JS first, but then after that it completely stopped getting rebuilt and the server had to be restarted to get any new changes. To see that this was happening, I created a dummy loader that just printed out when it was being called so I could see when the CSS and JS files were being compiled. Adding the I'm not exactly sure what's going on there, it seems like the virtual file changes aren't getting picked up by webpack after the first time, but it is really weird that they would get build once. I don't know if this is related to css-loader at all since I wasn't even seeing that get run after the first CSS build went through. Anyway, it would be nice to have a bit of documentation on |
See webpack-contrib/css-loader#1384 (comment) for more details. The tl;dr is this probably needs to add more data to the virtual module so class names generate correctly.
The text was updated successfully, but these errors were encountered: