@jonathan-chin can you please provide relevant environment information by running gatsby info --clipboard?

Also, I noticed that you are using Gatsby v1 from your package.json in the repo you shared. Please use gatsby-cli version 1.x.x for Gatsby v1. gatsby-cli version 2.x.x is for Gatsby v2

@kakadiadarpan

  System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i5-6360U CPU @ 2.00GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 9.4.0 - /usr/local/bin/node
    Yarn: 1.3.2 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Safari: 12.0
  npmPackages:
    gatsby: ^1.9.277 => 1.9.278
    gatsby-image: ^1.0.24 => 1.0.55
    gatsby-link: ^1.6.28 => 1.6.46
    gatsby-plugin-canonical-urls: ^1.0.11 => 1.0.18
    gatsby-plugin-google-analytics: ^1.0.12 => 1.0.31
    gatsby-plugin-google-fonts: 0.0.3 => 0.0.3
    gatsby-plugin-material-ui: ^0.1.3 => 0.1.3
    gatsby-plugin-nprogress: ^1.0.10 => 1.0.14
    gatsby-plugin-react-helmet: ^1.0.5 => 1.0.8
    gatsby-plugin-react-next: ^1.0.11 => 1.0.11
    gatsby-plugin-sass: ^1.0.26 => 1.0.26
    gatsby-plugin-sharp: ^1.6.48 => 1.6.48
    gatsby-remark-autolink-headers: ^1.4.8 => 1.4.19
    gatsby-remark-copy-linked-files: ^1.5.36 => 1.5.37
    gatsby-remark-external-links: ^0.0.4 => 0.0.4
    gatsby-remark-images: ^1.5.67 => 1.5.67
    gatsby-remark-responsive-iframe: ^1.4.19 => 1.4.20
    gatsby-source-filesystem: ^1.5.8 => 1.5.39
    gatsby-transformer-remark: ^1.7.21 => 1.7.44
    gatsby-transformer-sharp: ^1.6.14 => 1.6.27
  npmGlobalPackages:
    gatsby-cli: 2.0.0-rc.1
    gatsby: 1.9.278

when I downgrade my global gatsby-cli to 1.9.X, I get the CSS issue. when I keep it at 2.0.0-rc.1, it gives me the BrowserslistError: Unknown browser query dead error

@jonathan-chin I understand that you are getting the CSS issue with gatsby-cli version 1.9.x, but that is the version you should be using as it is compatible with Gatsby version you are using.

Thanks for sharing the reproduction repo. I'll take a look at that.

@jonathan-chin would it possible for you to tell which CSS is exactly differing in develop vs build?

@kakadiadarpan
This is from develop and is the styling expected

this is what I get from build:

You can see that their CSS classes are different.

I don't recall this being an issue before. The last good build (where CSS was not affected) was https://gitlab.com/sharemeals/gatsby-site/commit/4342a715d6a1cdcb2808e5450819753be6f56a19

I think the fix for this is #8092.

@jonathan-chin would you be able to pull the contents of that fix down, and then try with those changes? Note: if you haven't seen it yet, the How to Contribute section of Gatsby's docs contains info on how to get set up with gatsby-dev-cli, which you'll need to test it out!

Also @jonathan-chin looks like you're on Gatsby v1. Would you be able to upgrade to Gatsby v2 to get this fix?

@DSchau sorry it took me so long to get back to this.

migrating the existing project to v2 was too much work. I decided to start a new v2 starter and migrate it piece by piece (copying and modifying as needed). In this case, gatsby develop produces radically different output than gatsby build:

gatsby build

gatsby develop

comparing the css styles of two identical elements on build and develop:

build:

.jss94 {
  color: #fff;
  font-size: 0.875rem;
  font-weight: 500;
  font-family: "Roboto", "Helvetica", "Arial", sans-serif;
  text-transform: uppercase;
}

develop:

.MuiTypography-headline-88 {
  color: #fff;
  font-size: 1.5rem;
  font-weight: 400;
  font-family: "Roboto", "Helvetica", "Arial", sans-serif;
  line-height: 1.35417em;
}

I have some Material UI overriding scss that I load into the layout component in v2. in develop, it seems to merge them well but in build, it seems to be ignoring them? can that be the cause?

I just have an import '../scss/style.scss';

@jonathan-chin did you try this with v2 or as per steps mentioned in the comment by @DSchau above?

@kakadiadarpan Sorry, I don't have the capacity (ie time) to set up that work flow.

After looking at the PR fix, it seems to be the same issue I'm experiencing. I can close this issue for now and monitor the PR.

@kakadiadarpan sorry, I just realized something strange.

When my site first loads, the CSS is wacky. but forcing it to reload the index page, the CSS loads fine. Here are the steps to reproduce:

1) load https://sharemeals.org/
examine the emerson quote toward the bottom:

2) click on the top left site name. it will reload the index page without refreshing the site. the emerson quote appears as expected:

(the emerson quote is indicative of other CSS changes. I'm only calling this one out because it is the most visible)

@jonathan-chin Thank you for the update. I'm able to reproduce the issue with the steps that you provided. Are you using Gatsby v1 or v2 for https://sharemeals.org/?

~I'm having this exact same issue:~

~When using injectGlobal I'm getting diffent styles after running gatsby build. You can see the issue here: https://ivorpad.com/about~

~After the page finishes loading hover the links 'Writing' or 'Work' and you'll see the styles change.~

Solved it by moving the heading styles to page.js instead of global.

 System:
    OS: macOS High Sierra 10.13.5
    CPU: x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 8.11.4 - ~/n/bin/node
    Yarn: 1.2.1 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/n/bin/npm
  Browsers:
    Chrome: 69.0.3497.100
    Firefox: 62.0.2
    Safari: 11.1.1
  npmPackages:
    gatsby: ^2.0.7 => 2.0.8
    gatsby-plugin-google-analytics: ^2.0.0-rc.2 => 2.0.0-rc.2
    gatsby-plugin-google-fonts: ^0.0.4 => 0.0.4
    gatsby-plugin-react-helmet: ^3.0.0-rc.1 => 3.0.0
    gatsby-plugin-styled-components: ^3.0.0 => 3.0.0
    gatsby-plugin-typography: ^2.2.0 => 2.2.0
    gatsby-remark-prismjs: ^3.0.1 => 3.0.1
    gatsby-source-contentful: ^2.0.1-beta.15 => 2.0.1
    gatsby-transformer-remark: ^1.7.44 => 1.7.44

@kakadiadarpan that's using "gatsby": "^1.9.277"

I think the fix for this is #8092.

@jonathan-chin would you be able to pull the contents of that fix down, and then try with those changes? Note: if you haven't seen it yet, the How to Contribute section of Gatsby's docs contains info on how to get set up with gatsby-dev-cli, which you'll need to test it out!

@jonathan-chin can you try suggestions provided by @DSchau in this comment?

@kakadiadarpan I think I tried to implement this just now. I installed gatsby-cli-dev, forked and pulled, switched the branch, etc etc.

The issue still persists.

How can I double check that the new node_modules/gatsby that I have is correct and not the old one?

I've done some more investigating, with Gatsby 1.X.X and without the fix proposed.

(I tried upgrading to Gatsby 2.X.X and separately the fix proposed and neither worked)

the jss class for the desired style does exist on the initial pageload. in this case, .jss58. However, the element I'm looking at doesn't get .jss58 on the initial load. only after making another page request (even requesting the same page) will the element correctly get .jss58

So what's in charge of determining what jss classes to apply? is there a reason why it would have one result on initial load but a different load on all subsequent page requests?

EDIT: there are some other major issues. on production build, my svg icons never fully load, regardless of page request:

This is what I get instead on develop:

I am facing the same issue. The gatsby develop and gatsby build versions are very different for me.

If I land directly or refresh a page with material-ui components, the CSS is broken for those components. The classes are present in the source but they aren't applied to the elements. If I follow a <Link> to the same page, however, everything works fine.

I have also noticed that if I run gatsby build while gatsby develop is running, the gatsby develop version also starts behaving in exactly the same way as the gatsby build version.

System:
    OS: Linux 3.10 Red Hat Enterprise Linux Workstation 7.3 (Maipo)
    CPU: x64 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
    Shell: 4.2.46 - /bin/bash
  Binaries:
    Node: 11.1.0 - /usr/bin/node
    Yarn: 1.12.1 - /usr/bin/yarn
    npm: 6.4.1 - /usr/bin/npm
  Browsers:
    Chrome: 70.0.3538.77
  npmPackages:
    gatsby: 2.0.37 => 2.0.37
    gatsby-cli: 2.4.4 => 2.4.4
    gatsby-plugin-typography: 2.2.1 => 2.2.1
    gatsby-source-atom: 0.1.0 => 0.1.0
    gatsby-source-ghost: 2.1.2 => 2.1.2
  npmGlobalPackages:
    gatsby-cli: 2.4.4

(I have never used gatsby-plugin-offline)

You can check out the website at http://pawanhegde.netlify.com
The source is at https://gitlab.com/PawanH/pawanh.gitlab.io/tree/gatsbyjs

To see the "expected" version, click on any of the comically large icons near the bottom.

I haven't had the time yet to try the fix for #8092

I haven't had the time yet to try the fix for #8092

It did not fix the issue for me. I still see the same behaviour.

Expected

Actual

If I land directly or refresh a page... the CSS is broken for those components. The classes are present in the source but they aren't applied to the elements. If I follow a <Link> to the same page, however, everything works fine.

This is also happening exactly as described for me. I tried the fix in https://github.com/gatsbyjs/gatsby/pull/8092 and it worked for most pages, but did not work for all of them.

Expected:

Actual:

  System:
    OS: macOS High Sierra 10.13.5
    CPU: x64 Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 10.10.0 - /usr/local/bin/node
    Yarn: 1.9.4 - /usr/local/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 70.0.3538.102
    Firefox: 62.0.3
    Safari: 11.1.1
  npmPackages:
    gatsby: ^2.0.46 => 2.0.46 
    gatsby-image: ^2.0.20 => 2.0.20 
    gatsby-link: ^2.0.6 => 2.0.6 
    gatsby-plugin-catch-links: ^2.0.8 => 2.0.8 
    gatsby-plugin-flow: 1.0.2 => 1.0.2 
    gatsby-plugin-google-analytics: ^2.0.7 => 2.0.7 
    gatsby-plugin-manifest: ^2.0.9 => 2.0.9 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.1 
    gatsby-plugin-root-import: 2.0.4 => 2.0.4 
    gatsby-plugin-sass: ^2.0.4 => 2.0.4 
    gatsby-plugin-sharp: 2.0.12 => 2.0.12 
    gatsby-plugin-sitemap: ^2.0.2 => 2.0.2 
    gatsby-plugin-svgr: 2.0.0-alpha => 2.0.0-alpha 
    gatsby-remark-copy-linked-files: 2.0.6 => 2.0.6 
    gatsby-remark-images: 2.0.6 => 2.0.6 
    gatsby-remark-responsive-iframe: ^2.0.6 => 2.0.6 
    gatsby-remark-smartypants: 2.0.6 => 2.0.6 
    gatsby-source-filesystem: 2.0.8 => 2.0.8 
    gatsby-source-wordpress: 3.0.13 => 3.0.13 
    gatsby-transformer-remark: 2.1.12 => 2.1.12 
    gatsby-transformer-sharp: ^2.1.8 => 2.1.8 

I solved this issue by doing the following
in the index.js file I had

import 'injectSheet' from react-jss
import './../bootstrap.min.css'

by reversing the order I was able to specify the order in which I wanted to import css in the html.
So, my final code was

import './../bootstrap.min.css'
import 'injectSheet' from react-jss

Solution:Change order of imports
This solved the problem for me. Hopefully it does the same to you.

I'm having the same issues, among many others:

• develop runs nondeterministically, however, when it does run, it works fine.
• StaticQuery fails to finish loading images nondeterministically.
• build fails nondeterministically, usually seg faulting in image stuff.
• build output differs greatly from that of develop - this is the deal breaker.
• develop and build seem to interact with each other.

These issues are such a drag that they unfortunately seem to outweigh any of the benefit of Gatsby for me, and forcing me to switch back to Create React App.

I tried various workarounds like removing all inline styles and importing .scss in the child components rather than at root level.
Still the issue persists. This is really troubling

I'm using styled components, adding gatsby-plugin-styled-components in gatsby-config.js worked for me.

Having same issue.
Gatsby build applies different class name but I can see in React inspector proper class being applied.

System:
    OS: macOS High Sierra 10.13.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.14.2 - ~/.nvm/versions/node/v10.14.2/bin/node
    Yarn: 1.12.3 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v10.14.2/bin/npm
  Browsers:
    Chrome: 71.0.3578.98
    Firefox: 59.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.107 => 2.0.107
    gatsby-image: ^2.0.20 => 2.0.25
    gatsby-plugin-google-analytics: ^2.0.9 => 2.0.9
    gatsby-plugin-manifest: ^2.0.9 => 2.0.12
    gatsby-plugin-offline: ^2.0.16 => 2.0.19
    gatsby-plugin-react-helmet: ^3.0.2 => 3.0.4
    gatsby-plugin-react-svg: ^2.0.0-beta1 => 2.0.0-beta1
    gatsby-plugin-sass: ^2.0.7 => 2.0.7
    gatsby-plugin-sharp: ^2.0.16 => 2.0.16
    gatsby-remark-copy-linked-files: ^2.0.8 => 2.0.8
    gatsby-remark-external-links: ^0.0.4 => 0.0.4
    gatsby-remark-images: ^3.0.1 => 3.0.1
    gatsby-source-filesystem: ^2.0.12 => 2.0.12
    gatsby-transformer-remark: ^2.1.15 => 2.1.15
    gatsby-transformer-sharp: ^2.1.9 => 2.1.9
  npmGlobalPackages:
    gatsby-cli: 2.4.6

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! 💪💜

Please stay open.

Issue is still not resolved. Please stay open for a bit

  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i5-7287U CPU @ 3.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.10.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.7.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 72.0.3626.119
    Firefox: 65.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.35 => 2.1.4 
    gatsby-cli: ^2.4.10 => 2.4.10 
    gatsby-image: ^2.0.19 => 2.0.29 
    gatsby-plugin-emotion: ^4.0.3 => 4.0.3 
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.14 
    gatsby-plugin-manifest: ^2.0.7 => 2.0.17 
    gatsby-plugin-netlify: ^2.0.3 => 2.0.11 
    gatsby-plugin-netlify-cms: ^3.0.12 => 3.0.12 
    gatsby-plugin-offline: ^2.0.10 => 2.0.23 
    gatsby-plugin-purgecss: ^3.1.0 => 3.1.0 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.6 
    gatsby-plugin-sass: ^2.0.7 => 2.0.10 
    gatsby-plugin-sharp: ^2.0.10 => 2.0.20 
    gatsby-plugin-typography: ^2.2.2 => 2.2.7 
    gatsby-remark-copy-linked-files: ^2.0.7 => 2.0.9 
    gatsby-remark-images: ^3.0.1 => 3.0.4 
    gatsby-remark-relative-images: ^0.2.1 => 0.2.1 
    gatsby-source-filesystem: ^2.0.12 => 2.0.20 
    gatsby-transformer-remark: ^2.1.17 => 2.2.5 
    gatsby-transformer-sharp: ^2.1.7 => 2.1.13 
  npmGlobalPackages:
    gatsby-cli: 2.4.5

Issue is still not resolved. Please stay open for a bit

  System:
    OS: macOS 10.14.3
    CPU: (4) x64 Intel(R) Core(TM) i5-7287U CPU @ 3.30GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 11.10.0 - /usr/local/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.7.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 72.0.3626.119
    Firefox: 65.0.1
    Safari: 12.0.3
  npmPackages:
    gatsby: ^2.0.35 => 2.1.4 
    gatsby-cli: ^2.4.10 => 2.4.10 
    gatsby-image: ^2.0.19 => 2.0.29 
    gatsby-plugin-emotion: ^4.0.3 => 4.0.3 
    gatsby-plugin-google-analytics: ^2.0.8 => 2.0.14 
    gatsby-plugin-manifest: ^2.0.7 => 2.0.17 
    gatsby-plugin-netlify: ^2.0.3 => 2.0.11 
    gatsby-plugin-netlify-cms: ^3.0.12 => 3.0.12 
    gatsby-plugin-offline: ^2.0.10 => 2.0.23 
    gatsby-plugin-purgecss: ^3.1.0 => 3.1.0 
    gatsby-plugin-react-helmet: ^3.0.1 => 3.0.6 
    gatsby-plugin-sass: ^2.0.7 => 2.0.10 
    gatsby-plugin-sharp: ^2.0.10 => 2.0.20 
    gatsby-plugin-typography: ^2.2.2 => 2.2.7 
    gatsby-remark-copy-linked-files: ^2.0.7 => 2.0.9 
    gatsby-remark-images: ^3.0.1 => 3.0.4 
    gatsby-remark-relative-images: ^0.2.1 => 0.2.1 
    gatsby-source-filesystem: ^2.0.12 => 2.0.20 
    gatsby-transformer-remark: ^2.1.17 => 2.2.5 
    gatsby-transformer-sharp: ^2.1.7 => 2.1.13 
  npmGlobalPackages:
    gatsby-cli: 2.4.5

As referenced in https://github.com/gatsbyjs/gatsby/issues/11072 the problem should be resolved in 7058a256d2dcfab91259bdf00e811375737414e7.

Only in my specific use case @emotion/global was used for inserting global styling in the application. Somehow the code-splitting issues still persisted in combination with the @emotion/global functionalities.

Workaround fix

The following steps were taken to resolve the issues. Not a perfect solution but it worked in this setup.

1. Update to latest Gatsby build ^2.1.8
2. Find out where import { Global, css } from '@emotion/core' is used and move CSS styling in to a new file ./styles/global.css
3. Include the stylesheet in your production build with adding gatsby-brower.js to project root

// gatsby-brower.js

import './src/styles/globals.css'

1. Cleanup old cache and build folder rm -rf .cache && rm -rf public
2. gatsby build -> gatsby serve
3. Voilá 💁‍♂️

Notes

• I suspect a lot of above issues are caused by uncommon ways of inserting (global) styles V.S. CSS code-splitting issues mentioned in https://github.com/gatsbyjs/gatsby/issues/11072
• Probably the above solution workaround is a specific use-case fix.
• This tutorial on styling in Gatsby helped me resolve it

This is frustrating issue.

For me, animations done with react-pose namely in gatsby-browser.js and gatsby-ssr.js were doing some weird voodoo stuff, double rendering and some undeterministic css stuff where page would work on a second refresh.

I still cannot point to the exact problem, but inspecting and eventually stripping plugins down, removing libraries, _solved_ it.

While Gatsby, alongside other JS tools, can be awesome and flashy, be careful and responsible about (not) using it in production.

is it possible to share a new reproduction? Because when using css-in-js it might be something we can't fix as it's not our fault.

I encountered this issue too.

I added typography.js a few days ago. Then I realized the styles based on typography.js works fine in gatsby develop, but they are not available in gatsby build. I created the apps from the starter template,

I tried to upgrade the version, it doesn't work.
Then, I found there is a layout.css

My solution is to comment layout.css and it seems to fix this issue

Project after adding typography.js
https://github.com/Jasonlhy/Gatsbyjs-Blog/tree/ffb52973c21014b247a808e444319f8eede6eee6

Project after commenting out layout.css
https://github.com/Jasonlhy/Gatsbyjs-Blog/tree/658c7f8976d8d84a1fd28cb9aa6c99bbce2be9b3

@Jasonlhy This was exactly the issue for me. The layout.js file in my components folder is importing the layout.css file. Once I removed that import and ran npm run build and npm run serve again, the site showed up just fine. Thank you so much!

is it possible to share a new reproduction? Because when using css-in-js it might be something we can't fix as it's not our fault.

Hi @wardpeet, this just popped up in a project of mine when I added gatsby-plugin-styled-components, so here's a fresh reproduction of the issue continuing to happen on updated Gatsby:

EDIT: Turns out I don't have a reproduction anymore, because the problem keeps changing as I edit my styles. After deploying my next commit, the order of the imports changed again. My CSS is now the same in both dev and prod. The attached screenshots and description show what used to be happening though...

Description

Gatsby orders the <head> differently in development vs. production. When using gatsby-plugin-styled-components alongside global CSS, this can cause the CSS load order to differ between dev and prod, leading to unexpected visual bugs.

This is identical to #9908, which was closed along with a slew of similar issues in favor of of #9733, which in turn was closed because per @KyleAMathews it was fixed in #11800. However, I still see the behavior from #9908 after ensuring Gatsby is updated.

Steps to reproduce

I have a live (but non-minimal) example of the problem in this repo: https://github.com/vivshaw/vivshaw. This site has a chunk of global CSS including the Bulma CSS framework, then the rest of the site is done in styled-components. Production version is live on netlify.

Expected result

Both gatsby develop and gatsby build gatsby serve should look the same. Style load order should be consistent.

Actual result

When built for production we see the correct page styling:

But when we load it up with gatsby develop, the padding in the intro section has gone AWOL:

I did some digging, and figured out why. In production, Gatsby loads the global css chunk before the styled-components styles, as visible with the two highlighted lines here:

But in develop, the styled-components styles load first:

Why does this cause a bug? Well, I have the component tagged with both a Bulma class and a styled-components generated class. Both classes affect the padding properties, so whichever one loads last is the one that gets applied. In this case, it's easily solvable by simply removing the Bulma class. But I can imagine situations in which this load order behavior causes more complex problems to arise.

Environment

> gatsby info

  System:
    OS: Windows 10
    CPU: (4) x64 Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
  Binaries:
    Yarn: yarn install v0.27.5
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 118.04s. - ~\AppData\Roaming\npm\yarn.CMD
    npm: 6.4.0 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 2.7.13 - /c/Python27/python
  Browsers:
    Edge: 42.17134.1.0
  npmPackages:
    gatsby: ^2.3.16 => 2.3.16
    gatsby-image: ^2.0.37 => 2.0.37
    gatsby-plugin-eslint: ^2.0.4 => 2.0.4
    gatsby-plugin-layout: ^1.0.14 => 1.0.14
    gatsby-plugin-manifest: ^2.0.28 => 2.0.28
    gatsby-plugin-netlify: ^2.0.13 => 2.0.13
    gatsby-plugin-netlify-cms: ^3.0.17 => 3.0.17
    gatsby-plugin-offline: ^2.0.25 => 2.0.25
    gatsby-plugin-purgecss: ^3.1.1 => 3.1.1
    gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12
    gatsby-plugin-robots-txt: ^1.4.0 => 1.4.0
    gatsby-plugin-sass: ^2.0.11 => 2.0.11
    gatsby-plugin-sharp: ^2.0.32 => 2.0.32
    gatsby-plugin-sitemap: ^2.0.12 => 2.0.12
    gatsby-plugin-styled-components: ^3.0.7 => 3.0.7
    gatsby-plugin-webpack-size: 0.0.3 => 0.0.3
    gatsby-source-filesystem: ^2.0.29 => 2.0.29
    gatsby-transformer-remark: ^2.3.8 => 2.3.8
    gatsby-transformer-sharp: ^2.1.17 => 2.1.17

Thanks definitely, unsure how we could fix this, we might want to add some kind of sorting to head components.

Seeing the same kind of issues as mentioned above by @topherauyeung

Environment

gatsby info

  System:
    OS: macOS High Sierra 10.13.4
    CPU: (4) x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.7.0 - /usr/local/bin/node
    Yarn: 1.15.2 - ~/.yarn/bin/yarn
    npm: 6.4.1 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 73.0.3683.103
    Firefox: 66.0.2
    Safari: 11.1
  npmPackages:
    gatsby: ^2.3.24 => 2.3.27
    gatsby-image: ^2.0.39 => 2.0.40
    gatsby-plugin-manifest: ^2.0.29 => 2.0.29
    gatsby-plugin-material-ui: ^1.2.4 => 1.2.4
    gatsby-plugin-offline: ^2.0.25 => 2.0.25
    gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12
    gatsby-plugin-sharp: ^2.0.35 => 2.0.35
    gatsby-plugin-typography: ^2.2.13 => 2.2.13
    gatsby-source-filesystem: ^2.0.29 => 2.0.31
    gatsby-transformer-sharp: ^2.1.18 => 2.1.18
  npmGlobalPackages:
    gatsby-cli: 2.5.4

Having this issue as well. We have a gatsby repo that pulls components from an NPM library. The components import .scss files which are being injected into <head> in the wrong order on build. On develop, the gatsby repo's styles come last, so they take precedence, but on build they come first and are being overridden by the imported component's styles.

I've a similar problem maybe related to this, I load the styles dinamically, on gatsby develop the styles are relative to the current layout, on gatsby build all the styles inside 'source.less' are applied to the app layout too

componentDidMount() { require("./source.less") }

Found this issue too. But my case was a simple mistake.
I was using

<Button href="/path/to/page">blah blah</Button>

When I changed to use Gatsby Link, it works

<Link to="/path/to/page">
  <Button>blah blah</Button>
</Link>

Same problem. Keeping an eye on a solution while I attempt to debug.

Adding to this because I think it's related, but only been an issue recently:
I'm using Typography.js as well as Bootstrap - in production the bootstrap is overruled by typography.js which is what I want, but on the dev server the Bootstrap font styles are overriding my typography styles. This is pretty infuriating because I have to deploy the site to see what it really looks like. If anyone knows how I could overrule Bootstrap with typography.js in gatsby develop I'd really appreciate it

Adding to this because I think it's related, but only been an issue recently:
I'm using Typography.js as well as Bootstrap - in production the bootstrap is overruled by typography.js which is what I want, but on the dev server the Bootstrap font styles are overriding my typography styles. This is pretty infuriating because I have to deploy the site to see what it really looks like. If anyone knows how I could overrule Bootstrap with typography.js in gatsby develop I'd really appreciate it

Fixed this by just rebuild Bootstrap with what I wanted

Same issue here - https://github.com/gatsbyjs/gatsby/issues/16075

I'm experiencing an issue similar to what's been described here. Although I'm not using any CSS frameworks (all custom .sass), some styles, elements, and classes are processed differently between gatsby develop and gatsby build.

This is occuring on a page where I am checking for search parameters using URLSearchParams(window.location.search). With that, I am dynamically showing an element depending on whether or not a parameter exists. When going directly to the URL on develop, everything works fine. On build, everything is handled rather differently.

Expected (develop):

Actual (build):

Conditional Logic:

{(!!params ? !params.has('signup') : true) && (
    <div className={[ styles.form__element, styles.contact__message, ].join( ' ')}>
        <label htmlFor="message">
            Message
            <textarea required minLength="10" name="message" id="message" cols="30" rows="10" className={styles.form__control} placeholder="Questions, comments, etc..." />
        </label>
    </div>
)}

params is set by:

const params = typeof window !== `undefined` ? new URLSearchParams(window.location.search) : ''

System:
    OS: macOS 10.14.6
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 10.15.3 - /usr/local/bin/node
    npm: 6.10.2 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 76.0.3809.100
    Safari: 12.1.2
  npmPackages:
    gatsby: ^2.13.50 => 2.13.50
    gatsby-image: ^2.2.8 => 2.2.8
    gatsby-plugin-google-analytics: ^2.1.6 => 2.1.6
    gatsby-plugin-hotjar: ^1.0.1 => 1.0.1
    gatsby-plugin-manifest: ^2.2.4 => 2.2.4
    gatsby-plugin-offline: ^2.2.4 => 2.2.4
    gatsby-plugin-react-helmet: ^3.1.3 => 3.1.3
    gatsby-plugin-sass: ^2.1.4 => 2.1.4
    gatsby-plugin-sharp: ^2.2.9 => 2.2.9
    gatsby-plugin-sitemap: ^2.2.5 => 2.2.5
    gatsby-remark-external-links: 0.0.4 => 0.0.4
    gatsby-source-contentful: ^2.1.17 => 2.1.17
    gatsby-source-filesystem: ^2.1.8 => 2.1.8
    gatsby-transformer-remark: ^2.6.10 => 2.6.10
    gatsby-transformer-sharp: ^2.2.5 => 2.2.5
  npmGlobalPackages:
    gatsby-cli: 2.7.27

@j-651 I seem to be having the same issue. I read data from local storage and render class names conditionally, and the wrong class names get rendered. Any workarounds?

@OrKoN what I ended up doing to get around this issue was creating a separate page using the original pieces as a component and then passing in a prop to conditionally render, if that makes sense. Not sure if this works for your implementation.

I am having a similar issue. First, i was having different version because of styled components. I added the gatsby-plugin-styled-components plugin and those fixed itself. Then I noticed MaterialUI began to break so I added gatsby-plugin-material-ui and still no luck. The material UI is still broken on deployment.

Production:

Dev(Local)

I was able to reproduce my issue and isolate in the repo https://github.com/gatsbyjs/gatsby/issues/16925 it's related to the behavior of the link component and probably it's a different issue

This isn't a proper solution but just wanted to chime in with a quick fix I had to go with to get a project out the door.

I copy and pasted the output of typography.js, placed it in a .scss file, and made sure to import it afterward everything else, with a little message.

typographyjs-output.scss
Just ignore this file please and thank you!
I had to extract the CSS generated by typography.js and place it here.
Why? See here: https://github.com/gatsbyjs/gatsby/issues/8560
The production build imports SCSS and css-in-js in a different order from dev (not sure if it's always a consistent order).
I removed 'gatsby-plugin-typography', and import the CSS that was generated from that like a regular ol' stylesheet.
Typography.js was included in the project from the start and I didn't expect it to cause any issue.
So yeah - I styled the rest of the site with these defaults being included, so removing this file makes things look a bit weird.

Pretty terrible solution but it works if you're in a bind.

Something I just realized is that on initial page load the CSS is broken but change the page and then go back to the home page again and the CSS works. It's only on the initial page load that the CSS does not look right and also loads quite slow

With Material-UI I had a double call for the gatsby-plugin-material-ui in the gatsby.config.js. Initial page load had a flicker and some styles did not get added sometimes. Now it works with newest plugin version and this module export in the plugins array of gatsby.config.js:
, { resolve: 'gatsby-plugin-material-ui', // If you want to use styled components you should change the injection order. options: { // stylesProvider: { // injectFirst: true, // }, }, }

Did anyone find a solution here? I am seeing incorrect styling on production (first page view), even though local is fine. Eg. The component has jss13 and jss14 on production, but those classes should be jss43 and jss45. I am also seeing the order of styles in the head differ, but am lost as of how to solve...I have both the plugins included too, but no luck:

plugins: [
    'gatsby-plugin-styled-components',
    'gatsby-plugin-material-ui',
];

@ocundale For me, the fix was to remove material-ui method of styling. For example, the following code would cause issues when pushing to production. I don't know why but once I removed this and put this styling as inline css, everything worked as intended.

const MyTab = styled(Tab)({
  border: '1px solid grey',
  borderRadius: '50px',
  fontSize: '12px',
  marginRight: '16px'
})

Fixed by doing

<Tab style={{
 border: '1px solid grey',
  borderRadius: '50px',
  fontSize: '12px',
  marginRight: '16px'
}}>
...
</Tab>

OK, thanks @Skillz4Killz, appreciate the quick response, seems a shame, but I think I'll resort to using the same method then. Cheers!

This isn't a proper solution but just wanted to chime in with a quick fix I had to go with to get a project out the door.

My temporary fix was adding !important to every line in my css so it wouldn't get overridden by the template css. Brutal.

@gatsbyjs/core This issue seem to popping up all over this repository time and time again in different variations. #3741 #5100 #9911 #10370 #12360 #14601 #17676 #17728 (I'm sure there are more, I keep discovering them all the time)

This is a CRITICAL problem, as it has no clear workaround, affects sites non-deterministically, and often appears in "mysterious ways" as it has some very indirect side-effects. Changing attributes of the same HTML element -- especially class -- is a _very_ common use-case.

If what is said in #14601 is correct, then this is a problem with the consolidation of the hydration function introduced in React 16.

There is #10706 which only helps discovering this problem earlier in develop mode, but it does not fix it, as far as I understand.

For anyone else experiencing this, I managed to fix without using inline CSS/important.
Not a planned approach and felt more like luck really, but I added the _gatsby-plugin-material-ui_ and _gatsby-plugin-styled-components_ plugins together with upgrading Material-UI to versions > 4 and I no longer see the issues.

{
  resolve: 'gatsby-plugin-material-ui',
  options: {
    stylesProvider: {
      injectFirst: true,
    },
  },
},
'gatsby-plugin-styled-components',

"@material-ui/core": "^4.0.0",
"@material-ui/icons": "^4.0.0",
"@material-ui/styles": "^4.4.1",

I am able to reproduce the problem, at least one instance of it.

Create a new gatsby site from this repository, which was initially cloned from the default starter: https://github.com/eyalroth/gatsby-hydrate-bug

It barely has any dependencies / plugins:

$ gatsby info
  System:
    OS: Linux 4.4 Ubuntu 16.04.6 LTS (Xenial Xerus)
    CPU: (4) x64 Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
    Shell: 4.3.48 - /bin/bash
  Binaries:
    Node: 10.16.0 - ~/n/bin/node
    Yarn: 1.17.3 - /usr/bin/yarn
    npm: 6.11.3 - ~/n/bin/npm
  Languages:
    Python: 2.7.12 - /usr/bin/python
  npmPackages:
    gatsby: ^2.15.22 => 2.15.22
    gatsby-plugin-offline: ^3.0.8 => 3.0.8
  npmGlobalPackages:
    gatsby-cli: 2.7.44

The site has only 2 pages and a layout. The layout is automatically added to the 2 pages via wrapPageElement (pretty much the same code as in gatsby-plugin-layout). The layout wraps the page content with a div that has a class attribute set to the current time, while also appending the time as text beneath the page content.

Upon building (and serving) the site, navigating to the index and inspecting it in the developer tools, one can see that the time displayed in the page is not the same as in the div class attribute:

Navigating to the second page will correct this behavior, and you'll see that the time will be the same between the page content and the class attribute:

This will remain so as long as you keep navigating between the pages in the same window. If you happen to refresh the page or open it in a window, the inconsistency will creep back; you'll actually notice that the time in the class attribute will remain the same every time you refresh (hinting that it is cached). "Hard refresh" (CTRL + F5) will load the page properly.

This particular instance of the problem occurs only with gatsby-plugin-offline enabled, and it is directly affecting gatsby-plugin-layout, and possibly any other implementation of wrapPageElement.

The only workaround I've been able to come with up so far is to simply replace the hydrate function with render:

// gatsby-browser.js
const ReactDOM = require('react-dom')

export function replaceHydrateFunction() {
    return (element, container, callback) => {
        ReactDOM.render(element, container, callback)
    }
}

Again, this is a problem with the reconciliation of the hydrate method, as discussed in multiple issues in the React repository, such as https://github.com/facebook/react/issues/10591, https://github.com/facebook/react/issues/12713, https://github.com/facebook/react/issues/13260.

Do note that it may introduce a performance penalty, as the whole purpose behind the "hydration" is to increase performance over plain rendering.

We're closing this issue in favor of https://github.com/gatsbyjs/gatsby/issues/17914 to keep things organized.

@eyalroth I agree that this is _indeed_ an issue we need to resolve. Let's discuss this in https://github.com/gatsbyjs/gatsby/issues/17914 and get to the bottom of this

I also got this issue. the Gatsby develop environment was fine but in build when reloading the problem page. className's and even inline style was being stripped out of the certain tags. Which left me with an div with no attributes but all the children were rendered.

however when i changed route using the gatsby link router rather than full page refresh. it fixes the issue.

This drove me Mad for hours. I found a horrendous fix, probably not a good practice but it did work For now.

But I changed the (div) tag to (article)

Suddenly the

<div>

became

<article class="CartSummary-module--summary--3zJVn">

on build

It also worked with ul and pre.

Thanks for the crazy workaround @stefantrinh1 - I too am experiencing this crazy css behavior

If anyone wants to see it replicated, I have a public repo and have deployed both versions:

seems to work with @stefantrinh1 's article workaround
https://github.com/funkfinger/blog/tree/good
https://good.jaywiggins.com

does not work
https://github.com/funkfinger/blog/tree/bad
https://bad.jaywiggins.com

I had similar issue while conditionally trying to load a component based on the cookie value. Of course, this did not work as you have SSR on production (not sure why it works in dev mode though). Anyway, what I ended up doing is wrapping my check inside useEffect and checking which component to render once React takes over (rehydrates) on the client. You can use componentDidMount() for class components. After I implemented this, everything works as expected.

My problem was that I was using wrapPageElement and wrapRootElement in gatsby-browser.js but not in gatsby-ssr.js. Once I copied what I had over to gatsby-ssr.js things started working as expected. Please see @jlkiri 's response: https://github.com/gatsbyjs/gatsby/issues/22113#issuecomment-597432337

Same issue in 2020. Clicking on fixes the issue but on full reload issue is present.
"gatsby": "^2.19.45",
"react-custom-scrollbars": "^4.2.1",

i have same problem as emailnikola

25729

In my case, gatsby-plugin-minify was making this problem, which led the production build to reload all styles in the production build.