Stop code splitting CSS?

[KyleAMathews]

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.

Importing components (using .css files) in different orders, whether you're code-splitting or not, can make the order of CSS rules change. It's worse for code-splitting because the order can also change at runtime if user loads screens/components in different orders.
https://twitter.com/necolas/status/1084944571056803840?s=19

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.

[gu-stav]

@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.

[andrzejchmura]

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.

[KyleAMathews]

@gatsbyjs/core please comment! This would be a non-breaking change and would unbreak a lot of sites (or at least save frustration).

[pieh]

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

config.optimization = {
          runtimeChunk: {
            name: `webpack-runtime`
          },
          splitChunks: {
            name: false,
            cacheGroups: {
              styles: {
                name: "styles",
                test: /\.css$/,
                chunks: "all",
                enforce: true
              }
            }
          },
          minimizer: [
            // TODO: maybe this option should be noMinimize?
            !program.noUglify && plugins.minifyJs(),
            plugins.minifyCss()
          ].filter(Boolean)
        };

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:

• current master - https://5c59b1ee8a0f585323eeee7c--eloquent-boyd-9f6a7f.netlify.com/ - when you hover "go to page 2" we preload css and styling changes (wat)
• build with changed webpack config - https://5c59b235aeac6265940bd13c--eloquent-boyd-9f6a7f.netlify.com/ both rules are merged and one "wins" all the time - the result also seem consistent with what we see using style-loader in development so this is another win here (but would need more research than just this simple example)

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

[sidharthachatterjee]

@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?

[pieh]

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

[KyleAMathews]

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.

[kenlu89]

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

[KyleAMathews]

@kenlu89 can you run gatsby info in your site and post the output here?

[kenlu89]

@kenlu89 can you run gatsby info in your site and post the output here?

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

System: OS: macOS 10.14.3 CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz Shell: 3.2.57 - /bin/bash Binaries: Node: 10.15.2 - /usr/local/bin/node Yarn: 1.13.0 - /usr/local/bin/yarn npm: 6.8.0 - ~/.npm-global/bin/npm Languages: Python: 2.7.10 - /usr/bin/python Browsers: Chrome: 70.0.3538.67 Safari: 12.0.3 npmPackages: gatsby: ^2.3.24 => 2.3.24 gatsby-cli: ^2.4.15 => 2.4.15 gatsby-image: ^2.0.22 => 2.0.31 gatsby-plugin-algolia: ^0.3.0 => 0.3.0 gatsby-plugin-catch-links: ^2.0.12 => 2.0.12 gatsby-plugin-feed: ^2.0.14 => 2.0.14 gatsby-plugin-google-analytics: ^2.0.16 => 2.0.16 gatsby-plugin-manifest: ^2.0.22 => 2.0.22 gatsby-plugin-meta-redirect: ^1.1.1 => 1.1.1 gatsby-plugin-netlify: ^2.0.11 => 2.0.11 gatsby-plugin-offline: ^2.0.24 => 2.0.24 gatsby-plugin-react-helmet: ^3.0.8 => 3.0.8 gatsby-plugin-s3: ^0.2.5 => 0.2.5 gatsby-plugin-sass: ^2.0.10 => 2.0.10 gatsby-plugin-sharp: ^2.0.35 => 2.0.35 gatsby-plugin-sitemap: ^2.0.6 => 2.0.6 gatsby-plugin-typography: ^2.2.0 => 2.2.13 gatsby-remark-copy-linked-files: ^2.0.9 => 2.0.9 gatsby-remark-images: ^3.0.6 => 3.0.6 gatsby-remark-prismjs: ^3.2.4 => 3.2.4 gatsby-remark-responsive-iframe: ^2.0.9 => 2.0.9 gatsby-remark-smartypants: ^2.0.8 => 2.0.8 gatsby-source-filesystem: ^2.0.29 => 2.0.29 gatsby-transformer-remark: ^2.3.1 => 2.3.1 gatsby-transformer-sharp: ^2.1.15 => 2.1.15 npmGlobalPackages: gatsby-cli: 2.5.12

[stupidehorizon]

How can i reuse code splitting of css, because my all html have a big size

[xyy94813]

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.
When you site become more and more big.
It will cause performance issues.

Stop code splitting CSS do not solve the root cause of the problem

[tim-line]

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.

[kimbaudi]

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 gatsby build (and not during gatsby develop).

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 gatsby-node.js's onCreateWebpackConfig and setWebpackConfig or something.

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 pages folder can correctly import css/scss files during gatsby develop? Or is this only possible during gatsby build?