Webpack error querying mdx.html in GraphiQL

[notexactlyawe]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

Trying to query the field mdx.html from GraphiQL loads forever on the web interface and gives an error in the console running gatsby develop.

Query:

query MyQuery {
  mdx {
    html
  }
}

Console error:

 ERROR

Error: Conflict: Multiple chunks emit assets to the same filename output.js (chunks main and framework)
    at C:\Users\cmacl\src\mdx-bug-repro\node_modules\webpack\lib\Compilation.js:4610:12
    at C:\Users\cmacl\src\mdx-bug-repro\node_modules\webpack\lib\Cache.js:91:34
    at Array.<anonymous> (C:\Users\cmacl\src\mdx-bug-repro\node_modules\webpack\lib\cache\MemoryWithGcCachePlugin.js:116:13)
    at C:\Users\cmacl\src\mdx-bug-repro\node_modules\webpack\lib\Cache.js:91:19
    at eval (eval at create (C:\Users\cmacl\src\mdx-bug-repro\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:27:1)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Despite the environment below, this occurred in Firefox 100.0

Reproduction Link

https://github.com/notexactlyawe/mdx-bug-repro

Steps to Reproduce

1. Run gatsby develop
2. Visit http://localhost:8000/___graphq
3. Paste the query in the description into the interface
4. Click the play button
5. Observe the error

Expected Result

A GraphQL response for the query would be given.

Actual Result

GraphiQL shows a loading spinner and the gatsby develop output shows an error.

Environment

System:
    OS: Windows 10 10.0.22000
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 16.15.0 - C:\Program Files\nodejs\node.EXE
    npm: 8.5.5 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 3.10.4
  Browsers:
    Chrome: 101.0.4951.67
    Edge: Spartan (44.22000.120.0), Chromium (101.0.1210.53)
  npmPackages:
    gatsby: ^4.16.0-next.0 => 4.16.0-next.0 
    gatsby-plugin-mdx: ^3.15.0 => 3.15.0 
    gatsby-source-filesystem: ^4.15.0 => 4.15.0 
  npmGlobalPackages:
    gatsby-cli: 4.15.0

Config Flags

No response

[LekoArts]

Hi!

The html field doesn't work in gatsby develop, it's only accessible during gatsby build so that you can use it for e.g. the gatsby-plugin-feed.

One could add this limitation to this section: https://www.gatsbyjs.com/plugins/gatsby-plugin-mdx/#troubleshooting

[notexactlyawe]

Thanks for the quick response! I'd be happy to help change the docs.

Could you help me what the html field contains and the reason that we can't access it during gatsby develop? I'm wondering whether there's anything we can do to improve the error message in case a user doesn't think to look at the troubleshooting section.

[LekoArts]

I'm not 100% sure why that limitation exists and if we can warn against it, this is a bit before my time but I can check if I can get more infos on this.

It's defined here:

gatsby/packages/gatsby-plugin-mdx/gatsby/create-schema-customization.js

Lines 219 to 243 in 160bbf0

	html: {
	type: `String`,
	async resolve(mdxNode) {
	if (mdxNode.html) {
	return Promise.resolve(mdxNode.html)
	}
	const { body } = await processMDX({ node: mdxNode })
	try {
	if (!mdxHTMLLoader) {
	mdxHTMLLoader = loader({ reporter, cache, store })
	}
	const html = await mdxHTMLLoader.load({ ...mdxNode, body })
	return html
	} catch (e) {
	reporter.error(
	`gatsby-plugin-mdx: Error querying the \`html\` field.
	This field is intended for use with RSS feed generation.
	If you're trying to use it in application-level code, try querying for \`Mdx.body\` instead.
	Original error:
	${e}`
	)
	return undefined
	}
	},
	},

When you use it in e.g. your page/template, we already warn about it. But not inside GraphiQL. Adding directly a warning would be really good, but the minimum thing we can do is to add it to the docs for now.

Sidenote: With #35650 this might already change again, but that shouldn't be a concern for now.