Skip to content
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

Open
jsg2021 opened this issue Oct 13, 2021 · 9 comments
Open

css-loader 6.4.0 breaks astroturf #728

jsg2021 opened this issue Oct 13, 2021 · 9 comments

Comments

@jsg2021
Copy link
Contributor

jsg2021 commented Oct 13, 2021

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.

@jquense
Copy link
Contributor

jquense commented Oct 18, 2021

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)

@jquense
Copy link
Contributor

jquense commented Oct 18, 2021

err maybe if the locals convention was configured to use content hash that would work?

@jsg2021
Copy link
Contributor Author

jsg2021 commented Oct 18, 2021

@jquense yep, I've already done so. I'm following along on the css-loader issue

@jsg2021
Copy link
Contributor Author

jsg2021 commented Nov 3, 2021

err maybe if the locals convention was configured to use content hash that would work?

Sorry, I just noticed this. Could you elaborate? Is [contenthash] available for localIdentName?

@jquense
Copy link
Contributor

jquense commented Nov 4, 2021

it seems like it? I didn't think so but the webpack thread suggested it was

@evnp
Copy link

evnp commented Feb 2, 2022

Hey, just wondering if any changes were planned around this. We're currently working around it by pinning css-loader@6.3.0, 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.

@jquense
Copy link
Contributor

jquense commented Feb 3, 2022

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 :/

@evnp
Copy link

evnp commented Feb 4, 2022

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.

@robbprescott
Copy link

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 useAltLoader: true option for astroturf/loader successfully gets the CSS to rebuild every time.

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 useAltLoader, I just stumbled upon it in the code and figured I'd try it out and surprisingly it worked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants