[MDX] Fail gracefully on missing modules

[tesseralis]

Summary

Errors importing modules in MDX files shouldn't crash the gatsby build, but instead fail safely and either inline the import/component uses as text or

Basic example

The following example is from trying to use the Spanish gatsby docs translation into dot-org:

 ERROR #98123  WEBPACK

Generating SSR bundle failed

Can't resolve '../../../gatsby-source-git/docs-es/www/src/components/api-reference' in '/Users/tesseralis/Code/gatsby/www/.cache/caches/gatsby-plugin-mdx/mdx-scopes-dir'

File: .cache/caches/gatsby-plugin-mdx/mdx-scopes-dir/45a99f2f8d7f4d8dbda20042a29e25fd.js

Motivation

A compile error in MDX shouldn't cause the build to fail. If a site allows users to write MDX, or has translations of MDX files, a failure in one of those files shouldn't cause a build to fail.

[blainekasten]

Hey @tesseralis!

Can you help me understand why it shouldn't cause the build to fail? Seems like a compile error should fail a build. I'm likely missing some context or reason so would love to just understand better what you're thinking!

[tesseralis]

@blainekasten My specific use case is with the localizations of gatsbyjs.org. These localizations are kept in separate github repos that we pull in as a source using gatsby-source-git.

Currently, all imported components in MDX files use relative imports:

import APIReference from "../../components/api-reference"

The translations leave these lines unchanged, meaning that when we pull those sources in and transform them with gatsby-plugin-mdx, they show the error above and crash the build.

The immediate solution is to move components used in MDX to their own package, but that still leaves the possibility that an error occurs during translating that breaks MDX compilation, which in turn crashes the build. We currently have >10 translations being worked on, and an error in any one of them could cause the site to crash.

More generally, there's the idea of a site that allows users to create content using MDX and pulled in from contentful or some source that isn't the local file system (I don't know how good of an idea this is). This data stored somewhere else shouldn't cause the build to crash when it's pulled in.

[Rikpat]

I'm facing a similar issue, having a documentation website running on gatsby and multiple repositories for multiple products using gatsby-source-git, there's basically no quality control on the .md/.mdx files (you would not believe how many errors do those files contain. try explaining that
is not valid mdx). Having one faulty file in all of those repositories fails the whole build.

example of such error:

"gatsby-plugin-mdx" threw an error while running the onCreateNode lifecycle:
unknown: Expected corresponding JSX closing tag for <span> (28:92)

  26 | <p>{`#4620`}</p>
  27 | <ul>
> 28 | <li parentName="ul"><span style="color:red">**FQDN:  Web App or use Traffic manager?**<span></li>
     |                                                                                             ^
  29 | </ul>

Could there be some try/catch clause in onCreateNode that would take an onError option with possible values of "error" | "warning" and would only cause a warning that would not break the whole build, but only the faulty page?

[Stvad]

Wanted to raise this again - my use case is automatically generating content from source, that may contain some html code, I want to treat it as text though. So I've been trying to sanitize the input. But I'm not always successful, so sometimes mdx plugin tries to interpret content as jsx (and more often then not fails).

In such situations I'd like for build not to fail, but just get a warning or something like that.