Skip to content
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

Inconsistent CSS Styling Differs Between gatsby develop and build - Why? #9911

Closed
systemlevel opened this issue Nov 13, 2018 · 43 comments

Comments

@systemlevel
Copy link

commented Nov 13, 2018

develop:
images

build:
images-1

I don't even know where to start on this. I've cleared the .cache in the project folder to no avail.

Also, it's interesting to note that some styling was, in fact, maintained during the build. But other styling associated with the default fonts were not.

My bigger question is why does this occur? It would seem like the build should be the same as develop?

Thank you,

@lundgren2

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2018

I've had similar behaviour before. Have you tried to both remove .cache and node_modules, the lockfile and run npm install again?

Otherwise, what plugins are you using? are you running the latest version of Gatsby? You can also use e.g. Chrome DevTools to inspect the elements and see what css-classes used both under the "Styles" and "Computed" tabs.

@systemlevel

This comment has been minimized.

Copy link
Author

commented Nov 14, 2018

@lundgren2 Hi Tobias, I have tried removing the .cache folder in the main project folder. I will attempt to remove node_modules as well and give that a try.

I'm using the latest and greatest gatsby and gatsby-cli. The latest release as of right now.

Here are the plugins:

  plugins: [
    {
      resolve: 'gatsby-source-filesystem',
      options: {
        path: `${__dirname}/src/content/`,
        name: "markdown-pages",
      },
    },
    'gatsby-transformer-remark',
    'gatsby-plugin-favicon',
    'gatsby-plugin-react-helmet',
    {
      resolve: `gatsby-plugin-manifest`,
      options: {
        name: 'claims-portal',
        short_name: 'claims',
        start_url: '/',
        background_color: '#ccc',
        theme_color: '#ccc',
        display: 'minimal-ui',
        icon: 'src/images/brand.png', // This path is relative to the root of the site.
      },
    },
    'gatsby-plugin-offline',
  ],

When you had this similar behavior was it anything related to your plugins?

Thank you.

@lundgren2

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2018

Hi! I think it worked after I removed .cache and node_modules, but it was a long time ago.

I see you're using gatsby-plugin-offline, try to disable it and have a look at #5734

@kakadiadarpan

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2018

@systemlevel can you check if the CSS applied in develop and build is in a different order? I think it might be related to #9733

@systemlevel

This comment has been minimized.

Copy link
Author

commented Nov 14, 2018

@kakadiadarpan I can confirm that I am experiencing the same thing. The CSS styles are loading in different order.

screen shot 2018-11-14 at 11 57 18 am

screen shot 2018-11-14 at 11 58 58 am

You'll notice a slightly different CSS order between develop and build.

I'm using:

import styled from 'styled-components';

and I'm importing my CSS in the following way:

import 'bootstrap/dist/css/bootstrap.css';
import 'antd/dist/antd.css';

It could be similar to how #9733 is importing?

It sounds like there is a possible merge request to try and resolve this issue. If that is the case is there an update on that and is it known if that resolved the issue?

@systemlevel

This comment has been minimized.

Copy link
Author

commented Nov 14, 2018

As a followup question is there a better way to import the css files that would help develop and build be more consistent with each other?

import 'bootstrap/dist/css/bootstrap.css';
import 'antd/dist/antd.css';

I read about html.js and importing css into that file?

@systemlevel

This comment has been minimized.

Copy link
Author

commented Nov 15, 2018

I resolved this issue for my particular project. I don't know why it helps but it does. I have an import statement importing a .css file from my layout.jsx file.

Removing that and just importing the following from my other pages now provides consistent CSS styling between gastby develop and gatsby build

import 'bootstrap/dist/css/bootstrap.css';
import 'antd/dist/antd.css';
@nickensoul

This comment has been minimized.

Copy link

commented Nov 23, 2018

Same problem.
With this code in form component

import 'react-phone-number-input/style.css';
...
import './form.scss';

this is ok on development, but on production build styles from form.scss (regular sass styles) are has lower CSS-specify than react-phone-number-input (css imported from the npm module) due to order changed.
Tried @systemlevel solution but no luck.

@robertcoopercode

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2018

I have the same problem where my styles are loading in the incorrect order on production. Here is what the styles should look like:

image

When I move my cursor around on the page (over some navigation links for example), some additional CSS gets loaded onto the page that takes precedence over the "proper" CSS styles:

image

Live web page
Repository Link

It looks like the Sass that is imported into my layout component, doesn't load until a certain action is taken on the page (like hovering the cursor over a menu item), and then when the styles do get loaded on the page, they are taking precedence over other applied styles.

@pieh

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2018

@robertcoopercode This shows up in webpack manifest:

{
  "errors": [],
  "warnings": [
    "chunk 2 [mini-css-extract-plugin]\nConflicting order between:\n * css ./node_modules/css-loader??ref--12-oneOf-1-1!./node_modules/postcss-loader/lib??postcss-3!./node_modules/sass-loader/lib/loader.js??ref--12-oneOf-1-3!./src/styles/generic.scss\n * css ./node_modules/css-loader??ref--12-oneOf-1-1!./node_modules/postcss-loader/lib??postcss-3!./node_modules/sass-loader/lib/loader.js??ref--12-oneOf-1-3!./src/styles/meetup.scss",
    "chunk 2 [mini-css-extract-plugin]\nConflicting order between:\n * css ./node_modules/css-loader??ref--12-oneOf-1-1!./node_modules/postcss-loader/lib??postcss-3!./node_modules/sass-loader/lib/loader.js??ref--12-oneOf-1-3!./src/styles/reset.scss\n * css ./node_modules/css-loader??ref--12-oneOf-1-1!./node_modules/postcss-loader/lib??postcss-3!./node_modules/sass-loader/lib/loader.js??ref--12-oneOf-1-3!./src/styles/meetup.scss",
    "chunk 2 [mini-css-extract-plugin]\nConflicting order between:\n * css ./node_modules/css-loader??ref--12-oneOf-1-1!./node_modules/postcss-loader/lib??postcss-3!./node_modules/sass-loader/lib/loader.js??ref--12-oneOf-1-3!./src/components/Navbar/styles.scss\n * css ./node_modules/css-loader??ref--12-oneOf-1-1!./node_modules/postcss-loader/lib??postcss-3!./node_modules/sass-loader/lib/loader.js??ref--12-oneOf-1-3!./src/styles/meetup.scss",
    "chunk 2 [mini-css-extract-plugin]\nConflicting order between:\n * css ./node_modules/css-loader??ref--12-oneOf-1-1!./node_modules/postcss-loader/lib??postcss-3!./node_modules/sass-loader/lib/loader.js??ref--12-oneOf-1-3!./src/components/Footer/styles.scss\n * css ./node_modules/css-loader??ref--12-oneOf-1-1!./node_modules/postcss-loader/lib??postcss-3!./node_modules/sass-loader/lib/loader.js??ref--12-oneOf-1-3!./src/styles/meetup.scss"
  ],
  "namedChunkGroups": {
    "app": {
      "chunks": [10, 3],
      "assets": [
        "webpack-runtime-ad72934a1cd7e86ef2e0.js",
        "webpack-runtime-ad72934a1cd7e86ef2e0.js.map",
        "app-455c8069238d2cc1f942.js",
        "app-455c8069238d2cc1f942.js.map"
      ],
      "children": {},
      "childAssets": {}
    },
    "component---src-templates-about-page-js": {
      "chunks": [0, 1, 4],
      "assets": [
        "0-6a2f82352af15b51790d.js",
        "0-6a2f82352af15b51790d.js.map",
        "1-f411cd2313f4c0de2ccf.js",
        "1-f411cd2313f4c0de2ccf.js.map",
        "component---src-templates-about-page-js.36d8b9d651691e1c706a.css",
        "component---src-templates-about-page-js-32dd32dc5171b5b5f4e7.js",
        "component---src-templates-about-page-js-32dd32dc5171b5b5f4e7.js.map"
      ],
      "children": {},
      "childAssets": {}
    },
    "component---src-pages-index-js": {
      "chunks": [0, 2, 5],
      "assets": [
        "0-6a2f82352af15b51790d.js",
        "0-6a2f82352af15b51790d.js.map",
        "2.93f9cbd1985db92d9900.css",
        "2-624f3f8d504993f10076.js",
        "2-624f3f8d504993f10076.js.map",
        "component---src-pages-index-js.23f56e9796691a44934a.css",
        "component---src-pages-index-js-d3666208f2c9cdba4f1c.js",
        "component---src-pages-index-js-d3666208f2c9cdba4f1c.js.map"
      ],
      "children": {},
      "childAssets": {}
    },
    "component---src-templates-past-meetups-page-js": {
      "chunks": [0, 1, 2, 6],
      "assets": [
        "0-6a2f82352af15b51790d.js",
        "0-6a2f82352af15b51790d.js.map",
        "1-f411cd2313f4c0de2ccf.js",
        "1-f411cd2313f4c0de2ccf.js.map",
        "2.93f9cbd1985db92d9900.css",
        "2-624f3f8d504993f10076.js",
        "2-624f3f8d504993f10076.js.map",
        "component---src-templates-past-meetups-page-js.7339543e3309dcb3734c.css",
        "component---src-templates-past-meetups-page-js-2e59b30764d7fcce1697.js",
        "component---src-templates-past-meetups-page-js-2e59b30764d7fcce1697.js.map"
      ],
      "children": {},
      "childAssets": {}
    },
    "component---src-templates-sponsors-page-js": {
      "chunks": [0, 1, 7],
      "assets": [
        "0-6a2f82352af15b51790d.js",
        "0-6a2f82352af15b51790d.js.map",
        "1-f411cd2313f4c0de2ccf.js",
        "1-f411cd2313f4c0de2ccf.js.map",
        "component---src-templates-sponsors-page-js.d625f903723871c0c484.css",
        "component---src-templates-sponsors-page-js-7a1dd0bd2c5640c2935f.js",
        "component---src-templates-sponsors-page-js-7a1dd0bd2c5640c2935f.js.map"
      ],
      "children": {},
      "childAssets": {}
    },
    "component---src-pages-404-js": {
      "chunks": [0, 8],
      "assets": [
        "0-6a2f82352af15b51790d.js",
        "0-6a2f82352af15b51790d.js.map",
        "component---src-pages-404-js.7bbe236fd11ea765405b.css",
        "component---src-pages-404-js-c812802ad42e444ef167.js",
        "component---src-pages-404-js-c812802ad42e444ef167.js.map"
      ],
      "children": {},
      "childAssets": {}
    }
  },
  "assetsByChunkName": {
    "app": [
      "webpack-runtime-ad72934a1cd7e86ef2e0.js",
      "app-455c8069238d2cc1f942.js"
    ],
    "component---src-templates-about-page-js": [
      "0-6a2f82352af15b51790d.js",
      "1-f411cd2313f4c0de2ccf.js",
      "component---src-templates-about-page-js.36d8b9d651691e1c706a.css",
      "component---src-templates-about-page-js-32dd32dc5171b5b5f4e7.js"
    ],
    "component---src-pages-index-js": [
      "0-6a2f82352af15b51790d.js",
      "2.93f9cbd1985db92d9900.css",
      "2-624f3f8d504993f10076.js",
      "component---src-pages-index-js.23f56e9796691a44934a.css",
      "component---src-pages-index-js-d3666208f2c9cdba4f1c.js"
    ],
    "component---src-templates-past-meetups-page-js": [
      "0-6a2f82352af15b51790d.js",
      "1-f411cd2313f4c0de2ccf.js",
      "2.93f9cbd1985db92d9900.css",
      "2-624f3f8d504993f10076.js",
      "component---src-templates-past-meetups-page-js.7339543e3309dcb3734c.css",
      "component---src-templates-past-meetups-page-js-2e59b30764d7fcce1697.js"
    ],
    "component---src-templates-sponsors-page-js": [
      "0-6a2f82352af15b51790d.js",
      "1-f411cd2313f4c0de2ccf.js",
      "component---src-templates-sponsors-page-js.d625f903723871c0c484.css",
      "component---src-templates-sponsors-page-js-7a1dd0bd2c5640c2935f.js"
    ],
    "component---src-pages-404-js": [
      "0-6a2f82352af15b51790d.js",
      "component---src-pages-404-js.7bbe236fd11ea765405b.css",
      "component---src-pages-404-js-c812802ad42e444ef167.js"
    ]
  }
}

chunk 2 is where the most global/base css is (i.e. base .container styling), but it seems because of "Conflicting order" styles for about and sponsors pages are "weirdly" handled. In the issue about this warning there is some explanation - webpack-contrib/mini-css-extract-plugin#250 (comment) that might help. This jumping problem occurs because styles for those pages contain styles from generic.scss so those rules are loaded yet again and overwrite current rules (that come from chunk 2).

We should surface those warnings (even tho it's not really clear what's the proper fix - it's better to let user know something is problematic)

@robertcoopercode

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2018

Ah, I think I understand the issue! Thanks for the detailed answer. I'll just play around with the ordering of the Sass imports to find a way to more explicitly set order of the imports.

@pieh How did you generate that Webpack Mannifest (so I can see the warnings for myself)? Did you have to use the webpack-manifest-plugin?

@pieh

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2018

@robertcoopercode

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2018

@pieh I fixed the Webpack Manifest warnings regarding import ordering and the issue is still present, unfortunately.

@CanRau

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2018

Sadly I had to disable gatsby-plugin-offline as well to solve some inconsistencies 😢

@wangsongiam

This comment has been minimized.

Copy link
Contributor

commented Dec 27, 2018

FWIW, adding gatsby-plugin-styled-components in gatsby-config.js worked for me.

@pureth

This comment has been minimized.

Copy link

commented Jan 7, 2019

Incase it helps anyone!
We encountered a similar issue when importing global styles in our Layout component.
In develop mode the global styles were imported at the top of our CSS file, in build mode the global styles were imported at the bottom of our CSS file.
We got around this by adding our global styles to the gatsby-browser.js instead of importing them into the Layout component.

@sarahbethfederman

This comment has been minimized.

Copy link

commented Jan 8, 2019

I'm experiencing this issue too. All of my external css is being brought in in gatsby-browser.js and I'm using styled-components and not using plugin-offline. My css seems to be out of order on production

@sarahbethfederman

This comment has been minimized.

Copy link

commented Jan 8, 2019

So upon further digging, turns out the culprit was CSS that was coming from a component in my node_modules folder. I've manually added the import to the file in node_modules into gatsby-browser.js and it looks to be working now

@sarahbethfederman

This comment has been minimized.

Copy link

commented Jan 10, 2019

I take it back. This issue came back. It seems that on build, gatsby is pulling extra css from node_modules that's never actually imported by any code in use and the order is unpredictable so it overrides the css that is explicitly imported.

@DSchau

This comment has been minimized.

Copy link
Contributor

commented Jan 10, 2019

@sarahbethfederman could you provide any more detail on that? We haven't personally seen extra CSS be added as part of the build step--as far as we know!

We have seen (as this issue notes) the order of CSS imports change. Also is this something you can link to?

Minimal reproduction would be ideal--but we're aware that that might not be something that can be easily separated and abstracted.

Your help is very much appreciated on this issue! Thank you!

@marktrobinson

This comment has been minimized.

Copy link

commented Jan 17, 2019

I'm having this issue too where styles in build are re-ordered.

I was using a global.css imported through gatsby-browser.js but I just read that "Add global styles with CSS files and no layout component" cannot be used with CSS-in-JS which i'm fairly sure the gatsby-starter-blog uses.

I had to add create a layout.css and import it in my Layout component to get it to work.

See here: https://www.gatsbyjs.org/docs/creating-global-styles/

Any way to switch over to use css files oppsed to css-in-js?

@marktrobinson

This comment has been minimized.

Copy link

commented Jan 18, 2019

Actually that still didn't work... will have to look again this evening otherwise create an issue. On first load of the page the css isn't there, when i hover near a set of links (which is styled by the css) they change colour. No idea why! Will look into it

@elpuas

This comment has been minimized.

Copy link

commented Jan 25, 2019

Actually that still didn't work... will have to look again this evening otherwise create an issue. On first load of the page the css isn't there, when i hover near a set of links (which is styled by the css) they change colour. No idea why! Will look into it

I got the same issue when deploying to Netlify, it won't load styles correctly, until I Hover a Link

@reyberyturiaga

This comment has been minimized.

Copy link

commented Feb 12, 2019

I am also experiencing the same issue. Only happening when running gatsby build, running gatsby develop works fine. That's why I only catch this issue once I deployed to Netlify. The ordering of styles is inconsistent.

Here's my sample site: https://gatsby-tailwind-starter.netlify.com/

When initially visiting the site, the html element's overflow-y is being set to scroll (extra space is visible on the right side for the scrollbar), although I set it to auto on React Helmet via inline styling. I later discovered that Typography.js styling is taking precedence and overriding my custom styling.

When I click "Go to page 2", my 404 page is getting the proper styling. I also set overflow-y to auto via React Helmet and this time Typography.js is not interfering with it.

Finally, when I click "Go Home" on the 404 page, my home page will finally pick up my custom styling, and the extra space on the right side for the scrollbar is gone.

@DanielRuf

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

Sounds like node_modules is not excluded in the css loader setup or something similar.

Does it still happen with the latest release?

@reyberyturiaga

This comment has been minimized.

Copy link

commented Feb 12, 2019

@DanielRuf Yes, I am using Gatsby's latest release (2.0.118).

@ateev

This comment has been minimized.

Copy link

commented Feb 12, 2019

I'm experiencing the same issue. The css is just missing from the production builds.
Has the issue been identified ? Is the issue being worked upon ?

Would love to help in any way to resolve this soon :)

@reyberyturiaga

This comment has been minimized.

Copy link

commented Feb 12, 2019

@ateev The core team seems to be working on it. This is the resolution to watch out for:

#10706

Although, this will not guarantee that issues related to it will be fixed if it's merge, but at least we will be getting a consistent behavior on build and develop so we can catch potential issues early on before deployment occurs.

@KyleAMathews

This comment has been minimized.

Copy link
Contributor

commented Feb 15, 2019

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 gatsby@2.1.3 and lemme know if you're still having troubles!

#11072

@reyberyturiaga

This comment has been minimized.

Copy link

commented Feb 16, 2019

@KyleAMathews Still not working on my side. On initial load, react helmet styles is next to the critical css styling in hierarchy. On subsequent loads, it works fine. Can we ensure that react helmet styles is the last to load since it is where most people are putting their one-off custom styling if they decided not to use an external stylesheet to import? Maybe it's more of an issue with gatsby-plugin-react-helmet than gatsby core itself. The other culprit that I can think of is gatsby-plugin-typography since it is loading last in the hierarchy and introducing its own custom styling. Is it not recommended to pair Typography.js with global/css modules/styled-components workflow? In my use case, I am pairing it with Tailwind CSS (a utility css library). I am not using any reset, since Typography.js already include normalize.css by default but it is always getting a higher priority on the cascade on initial load which sometimes interfere with my other custom style.

I've found a workaround for now, by setting overrideStyles option of Typography.js to my desired styling but it would be great if React Helmet and Typography.js plugins would play nicer with each other out of the box.

@KyleAMathews

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2019

Oh you're putting CSS in react-helmet? Yes... that would have the same problem as splitting CSS did — as you're loading CSS in different orders so the cascade is unpredictable.

I'd highly not recommend using react-helmet in general for styles. Just use inline styles, css-in-js, or a .css file you import.

Hmmm re) typography.js — the only solution I see is for plugins to opt into a particular order in the <head>. BTW, in what order in your gatsby-config.js is your helmet & typography plugins?

@reyberyturiaga

This comment has been minimized.

Copy link

commented Feb 16, 2019

@KyleAMathews Yes. I am using react-helmet before to add some styling. I am just too lazy before to create a custom css since it's just a one-off styling and I'm quite sure I'll never add any other styling to it after that. But now that I look back into it, I realize that's react helmet is quite inflexible with this kind of stuff since it cannot even accept style declaration as an object as of now (See nfl/react-helmet#344).

I see, so the order of plugins is important when it comes to cascading of styles. I am indeed loading react helmet plugin before the typography plugin. When I think about it this way, the "odd" behavior I'm experiencing before now makes sense.

I can confirm that changing the order of the plugins did indeed fix my original issue, but I'm quite happy with my current setup and will be sticking with it for now.

Many thanks for the prompt response!

imyjimmy added a commit to imyjimmy/imyjimmy.github.io that referenced this issue Feb 17, 2019
…ring css load order in dev vs build: gatsbyjs/gatsby#9911. KyleAMatthews urges an update to 2.1.3.
@AndrejGajdos

This comment has been minimized.

Copy link
Contributor

commented Feb 18, 2019

I use gatsby-plugin-styled-components in my project and have the same issue.

@ajaymenon0

This comment has been minimized.

Copy link

commented Mar 4, 2019

I had to eventually resort to using overrideThemeStyles in typography.js to override the styles which were getting lower priority and hence never saw the light of day. For example:

Wordpress2016.overrideThemeStyles = () => {
  return {
    "a": {
      color: `#c0392b`
    },
  }
}
@kenlu89

This comment has been minimized.

Copy link

commented Apr 29, 2019

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.

@molebox

This comment has been minimized.

Copy link

commented Jul 2, 2019

Any movement on this? Im having the same issue where the style is rendered correctly locally but when built its not rendered at all. Its also strange that all of the styles are correctly rendered except one ( a button )

@yrammos

This comment has been minimized.

Copy link

commented Jul 30, 2019

Same here running Gatsby 2.13.41 (CLI 2.7.21).

@jamesvclements

This comment has been minimized.

Copy link

commented Aug 13, 2019

For anyone still struggling with this, I was using the gatsby universal starter and adding gatsby-plugin-styled-components in gatsby-config.js did not work for me until I deleted the starter's content in gatsby-ssr.js, both the wrapPageElement and replaceRenderer functions. I wasn't using either - you may need to play a bit more if you need both & are facing the inconsistent CSS issue

@shivbhar

This comment has been minimized.

Copy link

commented Aug 15, 2019

Unsure if this is a generalizable solution, but in case it can help anyone, the following worked for me [gatsby: 2.13.4, react-bootstrap: 1.0.0-beta.9, not using styled-components so didn't need the gatsby plugin]:

  • did not import CSS files into gatsby-browser
  • at this point, most of my styling was the same in dev and build
  • some react-bootstrap components (Nav, Navbar) still weren't styling correctly so rewrote them in vanilla html

Not the cleanest solution, but got things running. Stuck my css files in the components folder, but not sure that's necessary.

@srvkataria

This comment has been minimized.

Copy link

commented Aug 23, 2019

I tried a lot approaches to solve this problem as discussed on this thread & others. Some of these solutions were adding global CSS, Inline CSS, CSSinJS (reference link: https://www.gatsbyjs.org/tutorial/part-two/)

None of these approaches worked including trying to:

  • Disable gatsby-plugin-offline
  • Changing Import Orders
  • Deleting public & cache folders via gatsby-node.js script
  • Wrapping up elements using NoSsr in gatsby-ssr.js

My requirements were pretty straightforward:

  • The page design should be consistent on first load & subsequent loads (refresh)
  • The page design should be responsive to mobile, tablet, desktop media

I finally did it by re-writing CSS using gatsby-plugin-glamor. Using this approach, I were able to write Inline-CSS in JSX files with media query support.

I wasted 3 days on such trivial issues. I agree with the overall concept of SSR & static sites, but the way it has been implemented in gatsby is graceless.

It really drains you out: to figure out, debug & resolve simple design issues because these don't occur in the develop & suddenly flash on build. Moreover, the build page design changes on first page load & subsequent refreshes.

If you want to make your life hell, you should certainly go for gatsby.

@kokokenada

This comment has been minimized.

Copy link

commented Aug 30, 2019

@KyleAMathews - do you think this should be reopened? If the behaviour is different in develop mode and production mode, it's hard to see how it isn't a bug. And a lot people (including us) seem to be running into it.

@SuperKleber

This comment has been minimized.

Copy link

commented Aug 30, 2019

@josephkandi

This comment has been minimized.

Copy link

commented Sep 10, 2019

I am having this issue. Am using bootstrap with ant.design. ant.design automatically imports the styles for the components. My css override for the bootstrap headings and links is being overridden with the ant.design styles that are automatically imported.

Everything works fine during develop and changes in production.

Planning to move to use CRA instead, we've wasted a lot of time with gatbsy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.