Object exports trigger a fast refresh (MDX)

[dan-lee]

I am using Vite + MDX and a frontmatter plugin.

The plugin turns MDX into JSX + frontmatter export as const. Something like:

MDX		Transformed output
--- hello: frontmatter --- Rest of document	→ → → →	export const frontmatter = { hello: 'frontmatter' } export default function MDXContent() { return <p>Rest of document</p> }

Because the plugin exports an object and the heuristic of triple equals only does an identity check, every change triggers a full reload:

vite-plugin-react/packages/plugin-react/src/refreshUtils.js

Lines 37 to 44 in 2737d41

	const allExportsAreComponentsOrUnchanged = predicateOnExport(
	nextExports,
	(key, value) => {
	hasExports = true
	if (exports.isLikelyComponentType(value)) return true
	return prevExports[key] === nextExports[key]
	},
	)

It's not so straightforward to move the exports to another file, because this is a 'hidden' compilation step, and it would be quite awkward to move the exports into a separate file.

Repro on StackBlitz: Just edit the Test.mdx and see that it always does a full reload. If you remove the frontmatter part at the top, it actually does a fast reload.

I don't think it warrants a full page reload when a plain old object has changed. Is there a way to solve this gracefully?

One thing that comes to mind is to offer an option like customEquals that could be hooked into refreshUtils.js above, to enable customization for equality checks: e.g. if the key equals frontmatter I could do a deep equals, otherwise fallback to the default triple equals ===.

[ArnaudBarre]

Thanks for clearly exposing the issue. This is in my todo list and I will investigate it at some point, I don't have much time for now. This is an issue similar to what the future API for react-router v7 will have, so I definitely need to find a way to extends this

[hi-ogawa]

Can you elaborate more on the use case of frontmatter export?
I suppose either it's only used locally in the same file like { frontmatter.hello } or it's consumed by other files via import { frontmatter } from './Test.mdx'. For the latter use case, it might not be as simple as tweaking the equality there because the change needs to be propagated to the importer of frontmatter. But depending on the use case, there might be a short term workaround.

FYI, I had this PR on remix for mdx hmr remix-run/remix#7954 and Remix currently doesn't support hmr when mdx file includes frontmatter.

---

This is a trick I was thinking, but indeed this doesn't allow importers to react on change in frontmatter:
https://stackblitz.com/edit/vitejs-vite-beczdh?file=vite.config.ts

    {
      transform(code: string) {
        if (code.includes('export const frontmatter')) {
          // cheat `isLikelyComponentType`
          // https://github.com/facebook/react/blob/f5af92d2c47d1e1f455faf912b1d3221d1038c37/packages/react-refresh/src/ReactFreshRuntime.js#L717-L723
          code += `
            ;Object.defineProperty(frontmatter, "$$typeof", {
              enumerable: false,
              value: Symbol.for('react.memo')
            });
          `;
          return code;
        }
      },
    },

[dan-lee]

Yes, I mainly use it imported from other files and not consumed in the same file.
Very interesting workaround, thanks for sharing. I have similar issues with another remark plugin that creates a table of contents.

My guess is that this is just the tip of the iceberg and there will soon be other issues around such exports, as Arnaud mentioned.