feat: switch to xdm

[kentcdodds]

What: switch to xdm

Why: It's better than mdx-js

How: use dynamic imports which is how you maintain your own CJS-ness but import native ESMs. This is desirable for now.

Checklist:

• Documentation
• Tests
• Ready to be merged
  

[kentcdodds]

cc @Arcath and @wooorm

[kentcdodds]

Two issues:

Looks like xdm is considering all import syntax to actually just be strings. Not sure what's going on there...

Jest can't update the snapshots because the filename is "<stdin>" somehow 🙃

Other than this, I think syntactically this works ok and should work for folks using mdx-bundler!

[kentcdodds]

I couldn't figure out what was up with the <stdin> thing in Jest, but honestly I don't really care all that much. I'm tired of fighting this and hope that eventually it'll just fix itself. This is ready to rock and roll.

[kentcdodds]

Oh, and I tested this with remix and it totes works (when remix isn't compiling away the dynamic import, this has been reported).

[kentcdodds]

@all-contributors please add @wooorm for code

[allcontributors]

@kentcdodds

I've put up a pull request to add @wooorm! 🎉

[github-actions]

🎉 This PR is included in version 3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[Arcath]

@wooorm Using a providerImportSource of @mdx-js/react doesn't appear to be working as I'd expect it to from the docs.

I'm displaying it with this: (where components is an object of replacements).

   const Component = useMemo(() => getMDXComponent(source), [source])

  return <MDXProvider components={components}>
    <Component />
  </MDXProvider>

Is bundling or the way the client creates the component causing some issues here?

For completeness my bundleMDX is:

const {code} = await bundleMDX(source, {
    files,
    xdmOptions: (input, options) => {
      options.remarkPlugins = [
        remarkHighlight
      ]

      options.providerImportSource = '@mdx-js/react'

      return options
    }
  })

[kentcdodds]

If I understand it correctly, I think you could side-step the @mdx-js/react package entirely with:

   const Component = useMemo(() => getMDXComponent(source), [source])

  return <Component components={components} />

[wooorm]

@kentcdodds is correct here: in most cases, you don’t need to provider. I prefer being explicit and passing those components.

Still, it should be possible to use a provider. “Is bundling or the way the client creates the component causing some issues here?” I think so. I’m guessing that esbuild is bundling @mdx-js/react, which creates a context. And the client is using another @mdx-js/react, so with a different context?

[Arcath]

@kentcdodds yep that works. Its a TypeScript issue as components is not there as a prop in in the return type.

[kentcdodds]

Yeah, I realized that yesterday as well. Need to fix the typings

[Arcath]

#12 fixes the typings