gatsby build results in different CSS to that of gatsby develop #8560

Closed jonathan-chin closed 5 years ago

I just noticed this happen with my latest push. Up til then, it worked fine.

I have a Netlify account connected to GitLab and it builds and deploys from there.

I followed the suggested actions in #5734 but it didn't work for me. I don't think I use the offline plugin mentioned there either.

Notably, I recently had an issue with BrowserslistError: Unknown browser query dead. Downgrading my global gatsby package from 2.X to 1.9.X fixed that but might have caused this CSS issue as a result?

... How can I solve either of these problems?

The repo is public here: https://gitlab.com/sharemeals/gatsby-site

update it seems I have the gatsby-plugin-offline package in my package.json. However, removing it from there and from node_modules doesn't seem to make a difference. I might have installed it without actually implementing it.

@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 screen shot 2018-10-07 at 7 03 44 pm

gatsby develop screen shot 2018-10-07 at 7 03 48 pm

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: screen shot 2018-10-31 at 2 29 47 pm 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.

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

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


4. Cleanup old cache and build folder `rm -rf .cache && rm -rf public`
5. `gatsby build` -> `gatsby serve`
6. 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](https://www.gatsbyjs.org/tutorial/part-two/#using-global-styles) 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:

screenshot-prod

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

screenshot-dev

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:

production-source

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

dev-source

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 "fsevents@1.2.7" 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

gatsbyjs / gatsby