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 · 69 comments
Closed
Labels
status: awaiting author response Additional information has been requested from the author status: needs more info Needs triaging and reproducible examples or more information to be resolved

Comments

@systemlevel
Copy link

systemlevel commented Nov 13, 2018

People finding this thread, please check out enabling DEV_SSR which helps reduce or eliminate many css inconsistency problems #28138


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
Copy link
Contributor

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
Copy link
Author

@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
Copy link
Contributor

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
Copy link
Contributor

@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

@kakadiadarpan kakadiadarpan added status: needs more info Needs triaging and reproducible examples or more information to be resolved status: awaiting author response Additional information has been requested from the author labels Nov 14, 2018
@systemlevel
Copy link
Author

systemlevel 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
Copy link
Author

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
Copy link
Author

systemlevel 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
Copy link

nickensoul 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
Copy link
Contributor

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
Copy link
Contributor

pieh 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
Copy link
Contributor

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
Copy link
Contributor

pieh commented Dec 3, 2018 via email

@robertcoopercode
Copy link
Contributor

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

@CanRau
Copy link
Contributor

CanRau commented Dec 7, 2018

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

@casprwang
Copy link
Contributor

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

@jowo-io
Copy link

jowo-io 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
Copy link

sarahbethfederman 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
Copy link

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
Copy link

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
Copy link
Contributor

DSchau 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
Copy link

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
Copy link

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
Copy link

elpuas 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
Copy link

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
Copy link
Contributor

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

Does it still happen with the latest release?

@0x0verlord
Copy link

pretty bummed out to see this issue going on since 2.5.12 according to some that commented... pls fix?
"gatsby": "^2.18.5"
0 plugins used...

@thejamespower
Copy link

The issue still going strong. Non-deterministic builds make gatsby useless in almost every use case. This bug appears to have been around for years now. Can we please get an official response from a maintainer on what the plan of action is to fix this?

@DSchau
Copy link
Contributor

DSchau commented Dec 3, 2019

Hi @thejamespower!

Sorry to hear you're running into an issue. To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it.

If we can get that minimal reproduction, we can help ascertain exactly how we would fix this issue.

If you're up for it, we'd very much appreciate if you could provide a minimal reproduction and we'll be able to take another look.

Thanks for using Gatsby! 💜

@thejamespower
Copy link

thejamespower commented Dec 4, 2019

Hey @DSchau, I am trying to work on a repro', but without knowing why Gatsby is doing what it is currently doing, I'm unable to reproduce in isolation. I will continue to investigate.

For now, you can check: here and inspect the main heading 'LONDON'S TOOTH GEM COMPANY'. I have had to use !important to override the incorrect color styling as an example. Now I have figured out what's happening, if you inspect the <head>, you will see gatsby has injected two style tags. One pointing to /commons.28ad4b91b913acdfff74.css and another to /styles.de700ea0588bc94b16db.css. As far as I can tell, there is nothing in my setup that should be creating the commons file and of course, any styles in styles are overriding commons as this style tag comes after in the DOM. All the styles are using scss modules in the same way.

This doesn't happen during develop as gatsby is using link tags to correctly import all the css modules in development mode. Does gatsby have a maximum css file size that is causing it to take a random chunk of the output css and dump it in a commons file? In my isolated repros, there is only a styles...css, so I'm assuming it's only an issue in larger projects with numerous css rules?

@m-allanson
Copy link
Contributor

@thejamespower are you able to share the source of your site? If it's a private repo and you're able to invite me, that could work too.

The same goes for anyone else experiencing this issue. If you have:

That would help immensely in identifying the cause.

@dperrera
Copy link

dperrera commented Dec 20, 2019

I ran into this issue and was able to resolve it by copying the contents of my gatsby-browser.js into gatsby-ssr.js so they match as it mentions in the docs. During my debugging I changed exports.wrapPageElement to exports.wrapRootElement but I'm not sure if that had anything to do with it.

@joe-alfaro-anchorage
Copy link

@dperrera that worked for me

@mathieuforest
Copy link

@dperrera that was my issue. Thanks!

@DekiGk
Copy link

DekiGk commented Mar 15, 2020

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.

@eVocaTiv
Copy link

What worked for me :-

I was facing similar issues and none of the suggestions posted here worked for me.
I had been using 2 different versions of styled-components - the open source one for most of the components I made from scratch and the one from google's material UI for the components I took from that library, however the latter ones weren't reflecting on initialClientRender.

Ended up discarding material ui's styled components and using vanilla styled-components for all. Problem solved for me! Hope this helps someone.

@blainekasten
Copy link
Contributor

#25729

@theskillwithin
Copy link
Contributor

This solution does not work for me because I want to import 'swiper/swiper-bundle.css' only on the component that needs it

@jschaufele
Copy link

I am having the same issue w/ Fluent UI CSS - has there been any resolution ?? I have tried locating these files in layouts/gatsby-brower,gatsby-ssr - I am at my wits end and looks like I might have to abandon this ! I can't believe everything works as expected in dev then in prod it goes down the drain -

@pcolmer
Copy link

pcolmer commented Aug 11, 2020

@m-allanson I believe I have a fairly minimal demonstration at https://github.com/pcolmer/gatsby-bug-poc

Reproduction steps:

  1. gatsby develop
  2. Go to http://localhost:8000/ - you see a fairly bland page.
  3. Go to http://localhost:8000/test - you see a bootstrap spinner in the middle of the top of the page.
  4. Ctrl+C to stop Gatsby.
  5. gatsby build
  6. gatsby serve -p 8000

Repeat steps 2 & 3. Step 2 should look the same. For step 3, you should see the text "Loading..." in the top left corner of the page, because the bootstrap CSS isn't getting loaded.

Hope that helps.

@jschaufele
Copy link

jschaufele commented Aug 11, 2020 via email

@pcolmer
Copy link

pcolmer commented Aug 11, 2020

@m-allanson in trying to find a fix for the missing spinner in the production build, I seem to have uncovered another (related?) issue around Gatsby's CSS loading process.

In the same PoC repo, I've added a second branch, called "possible-fix". If you switch to that branch and then:

  1. gatsby build
  2. gatsby serve -p 8000
  3. Go to http://localhost:8000/test - the spinner is now there instead of the "Loading..." text.

So far so good. Stop Gatsby with CTRL+C.

  1. gatsby develop
  2. Go to http://localhost:8000/

Notice that I've added a nav bar and that the background is blue.

Open components/loading.js, comment out line 2 (import "../styles/minimal.scss") and save it.

Gatsby rebuilds the site ... and the nav bar's background changes to green, which is the colour it should be.

So you've edited a page that loads a CSS file. The page is not related to the frontpage and the CSS file is not used by the frontpage, yet that edit alters the appearance of the frontpage.

@m-allanson
Copy link
Contributor

Thanks @pcolmer! I'm not involved with Gatsby at the moment, so I'll tag @gatsbyjs/core for their attention.

@pcolmer
Copy link

pcolmer commented Aug 13, 2020

I've created a new issue now - #26434 - as I'm concerned that this issue (#9911) isn't getting any attention because it remains closed.

@hayyaun
Copy link

hayyaun commented Sep 17, 2020

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

@hazzyeer
Copy link

hazzyeer commented Nov 25, 2020

If by chance, you used useMediaQuery hook from material-ui and you put true for the option noSsr (useMediaQuery(theme.breakpoints.down("sm"), { noSsr: true });), most likely that this is the problem. Disabling this option, solved my problem.

@kilinkis
Copy link

kilinkis commented May 21, 2021

Still having this issue, can't really detect why it happens.
ATM, I have a return like this

return ({ someCondition ? <ComponentA /> : <ComponentB />})

and it renders all broken on build
but, when I had

return <ComponentA />

it was all good.

ComponentA and ComponentB are both Styled Components, if I use native tags like <div>hello</div> it works well

@KyleAMathews
Copy link
Contributor

People finding this thread, please check out enabling DEV_SSR which helps reduce or eliminate many css inconsistency problems #28138

@lewiss444
Copy link

I tried everything mentioned before and nothing worked. My solution was to rename the name of component to export and then everything was fixed like magic.

const IndexPage = () => {
  return (
      <Layout>
        <Seo/>
        ...
      </Layout>
  );
}
export default IndexPage

to

const HomePage = () => {
  return (
      <Layout>
        <Seo/>
  ...
      </Layout>
  );
}
export default HomePage

@Pebsie
Copy link

Pebsie commented Mar 3, 2022

Also getting this issue. How - after 3 years - is such a fatal problem still occurring? Gatsby really doesn't feel like a stable choice for any sort of web development right now. From outdated documentation, the majority of plugins being broken (with no indication on the plugin browsing site) and now when you finally get a site to build this happens. Forgive my tone, but after learning Gatsby and being excited about it it's devastating that it is in such a terrible, unusable state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: awaiting author response Additional information has been requested from the author status: needs more info Needs triaging and reproducible examples or more information to be resolved
Projects
None yet
Development

No branches or pull requests