-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Stop code splitting CSS? #11072
Comments
@KyleAMathews Another use case on not using code splitting would be building static prototypes. We do this quite often to hand over markup & styles to other teams, but currently we always have to add a second build step in order to create a CSS file containing all styles. |
What's the status of this issue? I've tried a few workarounds proposed on related issues and none of them seem to really work. I don't know if there's a need for another issue, as this problems are clearly connected to CSS splitting. I could create a minimal reproduction repo which shows this problem clearly, but an opt-in solution seems like the best option anyway. |
@gatsbyjs/core please comment! This would be a non-breaking change and would unbreak a lot of sites (or at least save frustration). |
I've done very crude test with this webpack config to force single css bundle (as documented in https://github.com/webpack-contrib/mini-css-extract-plugin#extracting-all-css-in-a-single-file):
and this repo as example https://github.com/pieh/gatsby-plain-css-test where I used duplicated styling rule imported by different page (blue background in test div on index and red background in test div on page-2) and here's result:
So for the cost of extra inlined bytes we get consistency which I think is worth it in the end and would vote to move forward with this |
@KyleAMathews This might be a breaking change for few where behaviour that they're currently seeing will change. As what we deem as incorrect behaviour might work for them? |
Those cases will have different problems like I tried to show in the demo - it's enough you hover over a link and it will load css for other page and potentially change styling for current page. Maybe if we had some kind of scoping that would help but I'm not sure how feasible that is and what issues we would have to solve first (f.e. how should common styles between pages behave - for example styles imported by shared components) - I just don't see automatic solution for style order / specificity that's feasible for us to do |
We could document how to restore code splitting if people did know that was happening and wanted it. Then it's on them to deal with implications. |
…by split CSS files loading in different orders Fixes #11072
Hello i'm having same issue with having two different result in dev and prod. Is there a solution for this? Running on latest 2.5.12 Gatsby |
@kenlu89 can you run |
@KyleAMathews here is our site github link https://github.com/franz-hartl/teachers . Try run on dev and build you will see two different style result. Thank you gatsby info:
|
How can i reuse code splitting of css, because my all html have a big size |
The CSS problem can be avoid by use CSS Modules or CSS specification. Even not use css splitting, the problem still in there exists. // pageA.js
import 'AComponent'
import 'BComponent' // pageB.js
import 'BComponent'
import 'AComponent' // AComponent.css
body {
color: red;
} // BComponent.css
body {
color: yellow;
} Consider more complex dependencies: // AComponent.js
import 'BComponent.js'; // BComponent.js
import 'AComponent.js'; Order-dependent problem not only in CSS splitting. Stop code splitting CSS will load unnecessary CSS in first page. Stop code splitting CSS do not solve the root cause of the problem |
Can anyone point me in the direction of the best way to tackle this currently? I have the same issue - large site and thus large general CSS files which we can't trim down. Without code splitting the CSS is too large and causes AMP validation to fail. With code splitting switched back we get lots of odd issues of slow loading CSS / styling breaking etc. We don't want to have two independent sites. Is there a work around? Tried posting on stack overflow with no luck so apologies if this is not the correct place to ask. |
I also want to mention that I faced a similar issue as @kenlu89 where my gatsby site looked different during development than in production. The issue for me is how Gatsby incorrectly handles css/scss imports during development imho. If I have 2 page components (home.js and about.js) and I import a css/scss file to just one page component (home.js), then Gatsby applies the css styling to the other page (about.js) during development (but not in production). I think Gatsby should only apply css/scss styling to page components that import css/scss files, but this only happens on If making css code splitting opt-in will resolve this issue, then please stop code splitting css and make it opt-in. Especially if there is another way we can configure css code splitting. Maybe via BTW, someone suggested gatsby-plugin-split-css plugin, but this doesn't work and I still get css styles applied globally to all pages during development. I guess this is expected behavior, but it feels more like a strange and unexpected side-effect. How can we configure gatsby-node.js so that each react component under |
We get many many big reports for v2 where people report weird CSS problem where depending on how they load the site and the order they visit pages, they get inconsitent styling.
These seem all related to splitting CSS as that means styles load in different orders changing the priority of rules.
We had far fewer problems in v1 without CSS splitting.
This tweet is also a good evidence for the problem.
CSS splitting can be useful for large sites. But given all the trouble it causes, it seems we should make it opt-in so people know what they're dealing with.
The text was updated successfully, but these errors were encountered: