tested his site and code changes aren't applying cleanly so trigger a refresh of the page. Not sure if this is something goofy with HMR, his site, or dev ssr. I suspect one of the early as I couldn't reproduce it on another site.

Others — if HMR breaks on your site, let us know!

Looks like you're in the wrong umbrella issue? But to answer your question — yes — MDX adds all of its code outside of pages so isn't affected by that. If you want to check out Query on Demand — that does help with most MDX setups #27620

Ah the link in the release notes pointed here: https://github.com/gatsbyjs/gatsby/blob/master/docs/reference/release-notes/v2.27/index.md#experimental-lazy-page-bundling-in-development

I'll repost my comment in the correct discussion, but briefly, it doesn't seem like Query on Demand helps in my case, most of my MDX files have imports using a fairly expensive webpack loader.

No worries, and thanks for the update. I created a new branch upgrading gatsby to v2.30, but unfortunately I'm still getting the same exact result as the images and original comment.

I've made the branch here: https://github.com/addisonschultz/Immaterial/tree/upgrade/gatsby

Do you have any other suggestions on where I could start looking? I'm serving all of my css directly into the default layout component, and not importing or calling it from anywhere else, so that should be the only entry point for the styles

did you add the DEV_SSR flag btw to your gatsby-config.js? That branch is gone now.

diff --git a/gatsby-config.js b/gatsby-config.js
index 454c78b..2e3f74a 100644
--- a/gatsby-config.js
+++ b/gatsby-config.js
@@ -1,4 +1,7 @@
 module.exports = {
+  flags: {
+    DEV_SSR: true,
+  },
   siteMetadata: {
     title: `Immaterial`,
     description: `VINTAGE, CONSIGNMENT, ART & MUSIC.`,

My changes locally.

Can you list the steps to reproduce the bug you're seeing? Perhaps record a little video? Thanks for helping test!

Hey Kyle, thanks again for helping me with this, hopefully this is helpful on your end as well.

Right now, I have everything on dev-ssr, and you can view it on my repo here.

As a quick overview, here's the situations where the styles are loading correctly and incorrectly:

NO ISSUES: yarn start (flag disabled)
NO ISSUES: yarn start (flag enabled)

ISSUES: yarn build && serve public(This skips the flag I believe)
ISSUES: Production (https://immaterialcorp.com) (See update below)

It loads the styles correctly only when navigating the site through gatsby-link and will show incorrect styles (most noticeable on index and /cart) when navigating directly to these endpoints.

I've made a video explaining some of the oddness that I'm experiencing:

https://www.dropbox.com/s/nbu56193n6c8u1e/bugs.mov?dl=0

Is there anything I should be looking for/at specifically? Many thanks in advance!

UPDATE 12/01/2021:
I've merged in a change outlined here that will rehydrate the page and serve the correct styles, but it's not the complete solution I was hoping for. I've updated the repository to include a branch dev-ssr that still faces these problems. Note as well that the prod version is not experiencing the issue anymore due to merging in this change, so you'll only be able to get into the odd state by running the repo locally.

Ok the reason the error wasn't happening in dev is the same as discussed below #28138 (comment)

Once the PR I made is in, you'll experience the same problem in dev.

The root problem though is you're using window.innerWidth to render https://github.com/addisonschultz/Immaterial/blob/69a042fc614885a5145e938728ecd74fcda57599/src/pages/index.js#L39

This doesn't work during SSR as window doesn't exist. You'll want to use media queries instead where you render both the mobile and desktop version but display none the version that version that shouldn't be enabled. That'll allow the React hydration to work.

hmm yeah odd indeed — endsWith should be work.

Turns out it only worked randomly ... now it is back to the scrambled page in the upper screenshot. :/

It's probably a separate problem not related to react-leaflet-geodesic, but the leaflet map in general ...

Is there a way to highlight this fix more broadly? The documentation only says stage === "build-html"

@acarnwath ah right — we've forgotten to update that page #29686

thank you for your excellent reproduction! Looking at it reminded me of this... very important TODO we forgot about haha

Changing from render to hydrate then produces this error in the console

PR #29016

I will test v2.31.0 when it is available..

DEV_SSR: true together with sass seems to work in gatsby@2.32.0-next.0. For me it seems that your changes is merged in that version @KyleAMathews.

🙏 yup, the PR is in the next version (2.31.0 will be out today).

Thanks for testing and glad it resolved things (for your site at least)! Keep the bug reports coming.

and out https://github.com/gatsbyjs/gatsby/blob/master/docs/docs/reference/release-notes/v2.31/index.md

Seems to work seamlessly now. Used it throughout the day. Thank you for the quick solution! Now we're able to get the benefits from the dev-ssr which we believe can ease the onboarding of new developers to our gatsby project.

excellent!

Can you open a new issue as it's not related directly to dev-ssr? This is a terminal rendering bug that's affecting a % of users but I haven't been able to reproduce. Perhaps, looking at your info, it's a linux thing? Getting all terminals to work the same is... challenging.

If you run GATSBY_LOGGER=yurnalist gatsby develop that should unstick you in the meantime.

Yes, It's not related directly to dev-ssr, it's related to all flags. GATSBY_LOGGER=yurnalist gatsby develop and gatsby develop --no-color working now. My other gatsby project doesn't have this issue.

This should be fixed on the latest versions — #29472

I suspect it's not related but it might be. Do you have a reproduction we could look at?

Sure! Here's a super minimal example: https://codesandbox.io/s/ic8eh
Changing to <2.30.0 for gatsby in package.json seems to resolve things.

Is this the source maps for Chakra or for your code? I do see source maps in the latest for code

For my own code - writing some fairly JS-heavy pages as part of the site so need to be able to debug :)

Neither locally on the Mac or when opening a Chrome browser through codesandbox I see any source map with v2.30. How did you get that working? :)

heh not sure. Source maps are weird sometimes IME and I never quite figure out why they stop working and why they come back.

Oh interesting. Is there any console output in this case?

[…] to delay rendering the dev overlays until after the first render

Sounds more pragmatic. Great👍

So has this been fixed @KyleAMathews -- because I see this error on every page load.

index.js:2177 Warning: Expected server HTML to contain a matching <span> in <div>.
    in span (created by ShadowPortal)
    in ShadowPortal (created by Indicator)
    in Indicator (created by LoadingIndicatorEventHandler)
    in LoadingIndicatorEventHandler (created by _default)
    in ConditionalFastRefreshOverlay (created by _default)
    in _default

and I get a message saying:

info We're shipping new features! For final testing, we're
rolling them out first to a small % of Gatsby users
and your site was automatically chosen as one of them.

Just got a fix merged into master #29692

master is now for upcoming v3 launch but I've marked it as one we can/should backport to v2 for release

@KyleAMathews I've still got this issue even with gatsby 3.2.0. I'm using wrapPageElement to provide some barebones layout, it looks like following:

<main>
  <h1>Lovely Page Title</h1>
  <div>{page}</div>
</main>

Unfortunately the page is not generated for the server HTML (although a normal gatsby build will generate this correctly). Therefore when the content loads on the client side, the same warning is generated: Expected server HTML to contain a matching <div> in <main>.

Interestingly for "pages" it works correctly (no error message), for "templates", i.e. stuff that is created with createPage it doesn't work (error messages + missing DOM content from server).

Could that be the smoking gun?

@KyleAMathews did you see the above?

I can reproduce this when I don't have the siteUrl set in gatsby-config.js as an option for the plugin.

I added a PR to validate this plugin's options #29688

I'm getting the same warning.

Same - easily reproducable on vanilla gatsby-starter-default

This is a hydration bug with gatsby-image as the warning is correct, the server generated HTML is different than the client — given gatsby-plugin-image is replacing it soon, we can probably ignore this #27950

That's correct. I run vercel dev locally. If you look at their documentation this is configured to run gatsby develop gatsby develop -p $PORT. Also after testing, If I disable the DEV_SSR flag, or if I simply run gatsby develop I don't get the error. Let me know if there is anything else I can do to help.

https://vercel.com/blog/vercel-dev#gatsby-and-node.js-functions

Having exactly the same issue.. same screen with the same error... starting the devserver with gatsby develop as usual, and we have only one version of react installed

hmm can't reproduce with vecel dev...

ok reproduced it w/ a site w/ gatsby-plugin-mdx — are the rest of you using mdx as well?

Actually I think it's just using hooks.

Anyways, this PR should fix things #29620

I ended up disabling the feature by adding

flags: {
  DEV_SSR: false,
}

into gatsby-config.js.

I am not planning to add SSR to my project at this moment but if I were to do so, I prefer to catch errors on develop and not on build. I would've used this feature.

This feature should only catch problems that'd prevent your site from building. Does gatsby build finish without errors.

Yes, I do have it. Here is the output:

success Building HTML renderer - 9.463s
failed Building static HTML for pages - 0.942s

 ERROR #95312 

"localStorage" is not available during server side rendering.

See our docs page for more info on this error: https://gatsby.dev/debug-html


  14 |
  15 | export const isLoggedInVar = cache.makeVar<boolean>(
> 16 |   !!localStorage.getItem("token")
     |     ^
  17 | );
  18 |


  WebpackError: ReferenceError: localStorage is not defined

I guess I'll have to re-enable the flag and fix it

I can confirm that I am on Gatsby 4.2.0 and with flags : { DEV_SSR: true } set in gatsby-config.js I get the warning

warn The following flag(s) found in your gatsby-config.js are not supported in your environment and will have no effect:
- DEV_SSR

However, if I set flags : { FAST_DEV: true } as I found mentioned in https://www.gatsbyjs.com/docs/reference/release-notes/v2.28/#feature-flags-in-gatsby-configjs, I get the following info output telling me that FAST_DEV is working, which supposedly includes DEV_SSR, QUERY_ON_DEMAND and LAZY_IMAGES (among other features) when enabled:

info The following flags are active:
- FAST_DEV · Enable all experiments aimed at improving develop server start time.
- PRESERVE_FILE_DOWNLOAD_CACHE · (Umbrella Issue (https://gatsby.dev/cache-clearing-feedback)) · Don't delete the downloaded files cache when changing gatsby-node.js & gatsby-config.js files.

There is one other flag available that you might be interested in:
- PARALLEL_SOURCING · EXPERIMENTAL · (Umbrella Issue (https://gatsby.dev/parallel-sourcing-feedback)) · Run all source plugins at the same time instead of serially. For sites with multiple source plugins, this can speedup sourcing and transforming
considerably.

This leads me to wonder if FAST_DEV toggles the DEV_SSR flag at all. When I look at #28331 (comment) about use of the FAST_DEV flag in a previous version of Gatsby, the log output showed that DEV_SSR was being used, among others. In my case, I only see PRESERVE_FILE_DOWNLOAD_CACHE having been enabled by FAST_DEV.

When I add export GATSBY_EXPERIMENTAL_DEV_SSR=true to my .zshrc config file, it is not clear to me in the terminal log of gatsby develop if DEV_SSR is indeed taking effect.

Last note here I promise. Even when having the environment variable set in my ZSH config and having it in my gatsby config, I still get this printed in the terminal when using Gatsby develop:

warn The following flag(s) found in your gatsby-config.js are not supported in your environment and will have no effect:
- DEV_SSR

@dko-slapdash , did you get some sort of confirmation in the console that DEV_SSR was indeed working for you?

i resolved this issue with aria-current mismatch from link with dev-ssr

to patch it's described here
#31996 (comment)

Running into the exact same issue!

Getting the same issue. Not sure how to solve it yet :(

Getting the same issue. Not sure how to solve it yet :(

Yes. We in my team have seen this issue quite often lately (many times a day), compared to a couple of weeks ago. I have not been able to recognize if this is connected to changes in components used in wrapPageElement (which, in my perspective, would make more sense) or if it is connected to changes in general.

While running gatsby develop, I got an error upon refreshing the page or trying to launch the site in a new tab or window.
This is what showed in my browser:
{"codeFrame":"No codeFrame could be generated","sourcePosition":null,"sourceContent":null}

I isolated the issue to the Helmet component from react-helmet.

I was using this code in a page template:
<Helmet bodyAttributes={{ style: "background-color: #f8f6f2;" }} />

I removed that component from my template and now I am able to refresh the page without getting the SSR error.

Hi @iamkimchico, I faced something similar which was a pain as the error wasn’t descriptive enough to find where the error is coming from.

error: {"codeFrame":"No codeFrame could be generated","sourcePosition":null,"sourceContent":null}

fix: For me, I had to review my previous changes and I found that I had two graphql queries that had the same name which was conflicting, and updating that did the trick. Hope this helps ✌️

after wrapping the gatsby cli in my own stderr and stdout i was able to get something:

Failed to validate error [Error [ValidationError]: "location.start.line" must be
 a number] {
  _original: {
    context: {
      sourceMessage: 'loadable: cannot find sidebar-sidebar-standard in stats
(from plugin: gatsby-plugin-loadable-components-ssr)'
    },
    filePath: 'src/pages/dev-404-page.tsx',
    location: { start: [Object] },
    text: 'There was an error while trying to load dev-404-page:\n' +
      'loadable: cannot find sidebar-sidebar-standard in stats (from plugin:
gatsby-plugin-loadable-components-ssr)',
    level: 'ERROR',
    category: 'SYSTEM',
    stack: [],
    docsUrl: 'https://gatsby.dev/issue-how-to',
    code: '11615'
  },
  details: [
    {
      message: '"location.start.line" must be a number',
      path: [Array],
      type: 'number.base',
      context: [Object]
    }
  ]
}

When using loadable and DEV_SSR, should we use hydrate?

https://www.gatsbyjs.com/plugins/gatsby-plugin-loadable-components-ssr/

module.exports = {
  plugins: [
    "gatsby-plugin-loadable-components-ssr",
    // OR
    {
      resolve: `gatsby-plugin-loadable-components-ssr`,
      options: {
        // Whether replaceHydrateFunction should call ReactDOM.hydrate or ReactDOM.render
        // Defaults to ReactDOM.render on develop and ReactDOM.hydrate on build
        useHydrate: true,
      },
    },
  ],
}

After restarting gatsby, I'm also getting this

Generating development SSR bundle failed

No template for dependency: ProvidedDependency

File:.cache/caches/gatsby-plugin-mdx/mdx-scopes-dir/947a288a9631feed031f2416c3ad5e97.j
     s

Any idea?

Update: I have disable all webpack cache with

export const onCreateWebpackConfigFunction: GatsbyNode['onCreateWebpackConfig'] = (
  { stage, rules, loaders, plugins, actions, getConfig, reporter, store },
  options
) => {
  const pluginOptions = options as unknown as GatsbyPluginTsCacheOptions;

  /**
   * Retrieve the initial gatsby webpack config
   */
  const config = getConfig() as Configuration;

  if (!config) {
    return void 0;
  }

  reporter.info(`[${pluginOptions.pluginName}]: replacing cache config`);

  /**
   * Replace the default caching strategy
   */
  config.cache = undefined;

  actions.replaceWebpackConfig(config);

And I no longer have crashes while refresh the page (with DEV_SSR enabled)

Update: updating to gatsby-plugin-loadable-components-ssr v3.4.0 seemed to have helped

How did you wrap the gatsby cli in your own stderr and stdout ?