Cannot get Formatted MDX to show for Blog Posts. Getting ERRORs now.

[davidkartuzinski]

I am updating to Gatsby v4 from a theme I coded three years ago.

Following the new tutorial I was able to create new pages using {mdx.frontmatter__slug.js} and <MDXProvider> with almost no issues. [{children} never worked for me without using <MDXProvider>..., but it eventually worked great!]

rendering worked like this. on my MAIN branch.

However, using {mdx.frontmatter__slug.js} did not allow for me to create PREVIOUS/NEXT blog page navigation like this as I did before here 3 years ago with gatsby-node.js and createPages.

Using gatsby-node.js and createPages everything is working as expected EXCEPT the body of my MDX blog posts. They are rendered unformatted if I use data.mdx.body and {children} doesn't work with either <MDXRenderer> or <MDXProvider> or by itself.

Under my Develop branch, the unworkable code.

I have tried everything, but using <MDXRenderer> or <MDXProvider> - I get the following error message:

Unhandled Runtime Error
Close
One unhandled runtime error found in your files. See the list below to fix it:


Error in function createFiberFromTypeAndProps in ./node_modules/react-dom/cjs/react-dom.development.js:28389
Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports. Check the render method of `BlogPost`.

and

./node_modules/react-dom/cjs/react-dom.development.js:28389

  28387 |           }
  28388 |
> 28389 |           throw new Error('Element type is invalid: expected a string (for built-in ' + 'components) or a class/function (for composite components) ' + ("but got: " + (type == null ? type : typeof type) + "." + info));
  28390 |         }
  28391 |     }
  28392 |   }

I have searched everywhere.

from the docs Using Page templates, whenever I try to destructure like this referring to data, the example, function PostTemplate({ data: { mdx }, children }). I get errors saying data is not defined.... And the rest of the example using just {children} does not work for me. function PostTemplate({ data, children }) doesn't work for me.

from the tutorial here on Part 6 this never worked for me. I had to use <MDXProvider>.

Even @LekoArts great blog, prev/next tutorial - does not work for me with formatted markdown.

Please help. I have looked into every theme and there doesn't seem to be any one of them employing Gatsby v4 with {children}, {mdx.frontmatter__slug.js}, and PREV/NEXT.

Thank you.

[ovflowd]

Same here, Gatsby Plugin MDX v4 is unusable. Can't make it work at all, it doesn't matter how hard I try.

This is quite stupid as there are no examples out there using the v4 of the plugin.

[PaulieScanlon]

Not that I know of. Is there a --fix arg you can pass? Making the changes
manually might be slower but you will at least be able to check the changes are correct before committing.

[PaulieScanlon]

Using the advanced find and place in VS Code will allow you to make changes in bulk, rather than one by one. Eslint is probably only for catching the errors, rather than fixing them, if you know what I mean.

[ovflowd]

I need to remind you that our docs are maintained in another repository that honestly couldn't care less about MDX/MD standards, we use our own thing. (Which is still compliant with general Markdown)

What I'm trying here is a best effort to make it be compatible with MDXv2 by running a script. It is truly bothersome that MDXv2 has such a restricting syntax that many other Markdown parsers, such as Remark, CommonMark and others are just fine with it.

Sorry, not gonna proceed with MDXv2, and I truly hope that the Gatsby team at least:

• Keep support to MDXv1 as many are using it
• Very nicely fix the memory leaks of gatsby-plugin-mdxv3 that cause Babel runtime code generator to scream. That'd be amazing, for real.

Thanks, and have a good one!

[PaulieScanlon]

Hey @ovflowd with regard to your other questions would you be able to start separate discussions. Whilst in your case they are all kind of related it might help us and others if you split them out into different discussions.

[ovflowd]

Sure thing 😄

[PaulieScanlon]

Hey @ovflowd i think this is the right move for you. If you don't want to, or can't fix the issues introduced by upgrading a major version of a package then it's probably best to stick with the older version.

[ovflowd]

If you don't want to,

It's not ideal to make such assessment when I'm actually trying to make the migration for the last days already. There still open questions that haven't been answered and they're blockers for our migration.

Don't get the wrong idea, I'd be more than happy to migrate to V2, but, the Node.js project is massive and enforcing such a big change on our documentation schema is not trivial.

Also, there are still open questions regarding Internationalisation and other things I asked that weren't answered, and it'd be great to be answered. 🙇