Gatsby: CSS order messed up after build

Created on 6 Nov 2018  ·  14Comments  ·  Source: gatsbyjs/gatsby

Hi everyone, I have an issue where my css is either missing or order is messed up after I build.
For example:

This is the development one.
screen shot 2018-11-06 at 12 26 42 pm

And this is one after I build
screen shot 2018-11-06 at 12 26 56 pm

My way of working is I use traditional way of writing in CSS file and import './index.css' into my component.

Is there anything I can do to fix this? Thank you!

stale? bug

Most helpful comment

I've found more issues in my project, and fixing these led to fixing the CSS issue.

I have my CSS imported in a file called Layout.js, which is the solution described in the Gatsby docs.

What fixed it for me

  • Always use the global layout.
    There were pages that didn't use the "global" layout, and I was importing CSS from the global layout. This resulted in a different CSS order per page, depending on what page is used as the entry point.

    The solution was to make sure every page uses the global layout as much as possible.

  • Never put non-page components in src/pages/.
    Some Gatsby projects end up keeping components into src/pages/ alongside the pages they're used in. This causes the issue above. It can show up in a structure like this:

    src/
    pages/
      index.js    # Home page
      HomeNav.js  # ⚠ Navigation component used by index.js ⚠
    

    In the example above, if HomeNav.js isn't meant to be a page, it should be moved to src/components/ (or wherever you choose to keep components). Otherwise, Gatsby will create a /HomeNav/ page, and the caveats of layout-less pages (above) would apply.

  • Never import components before the layout.
    The order of imports matter. The layout should be imported first. This is ok:

    import React from 'react'
    import Layout from '../layouts/Layout'
    import Nav from '../components/Nav'
    

    But this has the potential to cause problems:

    import React from 'react'
    import Nav from '../components/Nav'
    import Layout from '../layouts/Layout' /* ⚠ this should be above other components! */
    

Why is this a problem?

  • If you have pages that don't use the global layout, it won't do the import 'global.css' that's in Layout for that page. Instead, whatever CSS it uses will be imported first. This can confuse mini-extract-css-plugin on how to resolve CSS ordering (more on that on the next point below).

  • In the bad example, the line import 'global.css' from Layout will happen after Nav's import 'Nav.module.css' (for example). This tells mini-css-extract-plugin that the Nav.module.css should come before global.css, which isn't what you want.

  • If there are other pages that import Nav before Layout (and the other way around), this will get mini-css-extract-plugin confused on what is the correct order of CSS. It may pick the right one, or the wrong one. To fix this ambiguity, always import your components in proper order (Layout first!).

All 14 comments

@nzwnabdulwahid There are a couple of issues similar to this one #1836 & #6302. Also, #6302 has an open PR(#8092) which once merged should resolve this issue.

@DSchau @pieh should we merge these issues as they all are related to the ordering of the imported CSS(or SASS)?

Same here! In development i see everything right but after build all styles are messed...

The only workaround I did for now is I make sure in my css I code to be more specific :

.custom-button { background-color: green; }

to

button.custom-button { background-color: green; }

just to make sure its sorted highest in css precedence level.

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

As far as I know, this issue still exists.

Yes, still having the same issue.

I am seeing this issue as well. I would have thought using CSS modules would protect from this, but I guess it is more an issue of which order the imports happen than having scoped stylesheets?

I published a fix for this where we're not code splitting CSS which should solve the problems y'all are facing. Please update to [email protected] and lemme know if you're still having troubles!

https://github.com/gatsbyjs/gatsby/issues/11072

Still have this issue in April 2019.

Same here with Gatsby 2.4

Some debugging notes:

I've encountered this too. I tried to do gatsby build, which generated /public/webpack.stats.json. I checked it out and found some warnings:

image

I found that whenever I was doing import 'some-stylesheet.css' (in my components or in gatsby-browser.js, Gatsby's docs has some info on this), they showed up there.

Related:

I've found more issues in my project, and fixing these led to fixing the CSS issue.

I have my CSS imported in a file called Layout.js, which is the solution described in the Gatsby docs.

What fixed it for me

  • Always use the global layout.
    There were pages that didn't use the "global" layout, and I was importing CSS from the global layout. This resulted in a different CSS order per page, depending on what page is used as the entry point.

    The solution was to make sure every page uses the global layout as much as possible.

  • Never put non-page components in src/pages/.
    Some Gatsby projects end up keeping components into src/pages/ alongside the pages they're used in. This causes the issue above. It can show up in a structure like this:

    src/
    pages/
      index.js    # Home page
      HomeNav.js  # ⚠ Navigation component used by index.js ⚠
    

    In the example above, if HomeNav.js isn't meant to be a page, it should be moved to src/components/ (or wherever you choose to keep components). Otherwise, Gatsby will create a /HomeNav/ page, and the caveats of layout-less pages (above) would apply.

  • Never import components before the layout.
    The order of imports matter. The layout should be imported first. This is ok:

    import React from 'react'
    import Layout from '../layouts/Layout'
    import Nav from '../components/Nav'
    

    But this has the potential to cause problems:

    import React from 'react'
    import Nav from '../components/Nav'
    import Layout from '../layouts/Layout' /* ⚠ this should be above other components! */
    

Why is this a problem?

  • If you have pages that don't use the global layout, it won't do the import 'global.css' that's in Layout for that page. Instead, whatever CSS it uses will be imported first. This can confuse mini-extract-css-plugin on how to resolve CSS ordering (more on that on the next point below).

  • In the bad example, the line import 'global.css' from Layout will happen after Nav's import 'Nav.module.css' (for example). This tells mini-css-extract-plugin that the Nav.module.css should come before global.css, which isn't what you want.

  • If there are other pages that import Nav before Layout (and the other way around), this will get mini-css-extract-plugin confused on what is the correct order of CSS. It may pick the right one, or the wrong one. To fix this ambiguity, always import your components in proper order (Layout first!).

I was running into this issue on [email protected], but I'm pretty sure my cause was because I had followed the instructions here for replacing third party modules at build time with null effectively.

Well that module I was replacing includes it's own styles. In development everything worked great, I had my own styles that were overriding that modules styles. But in production, since that module gets skipped effectively, when it loads up in the browser, _then_ it's styles get imported (after all my other styles), so overriding wasn't working.

My current workaround isn't great but it works, I'm just adding !important to all of my overriding styles.

@rstacruz _Thank you!_ 🙏

The import order was what was causing this for us.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

3CordGuy picture 3CordGuy  ·  3Comments

dustinhorton picture dustinhorton  ·  3Comments

ghost picture ghost  ·  3Comments

theduke picture theduke  ·  3Comments

kalinchernev picture kalinchernev  ·  3Comments