mdx-bundler 🦤

Compile and bundle your MDX files and their dependencies. FAST.

---

[![Build Status][build-badge]][build] [![Code Coverage][coverage-badge]][coverage] [![version][version-badge]][package] [![downloads][downloads-badge]][npmtrends] [![MIT License][license-badge]][license] ![All Contributors][all-contributors-badge] [![PRs Welcome][prs-badge]][prs] [![Code of Conduct][coc-badge]][coc]

The problem

You have a string of MDX and various TS/JS files that it uses and you want to get a bundled version of these files to eval in the browser.

This solution

This is an async function that will compile and bundle your MDX files and their dependencies. It uses MDX v3 and esbuild, so it's VERY fast and supports TypeScript files (for the dependencies of your MDX files).

Your source files could be local, in a remote github repo, in a CMS, or wherever else and it doesn't matter. All mdx-bundler cares about is that you pass it all the files and source code necessary and it will take care of bundling everything for you.

FAQ:

<strong>
  "What's so cool about MDX?"
</strong>

MDX enables you to combine terse markdown syntax for your content with the power of JSX components. For content-heavy sites, writing the content with straight-up HTML can be annoyingly verbose. Often people solve this using a WSYWIG editor, but too often those fall short in mapping the writer's intent to HTML. Many people prefer using markdown to express their content source and have that parsed into HTML to be rendered.

The problem with using Markdown for your content is if you want to have some interactivity embedded into your content, you're pretty limited. You either need to insert an element that JavaScript targets (which is annoyingly indirect), or you can use an iframe or something.

As previously stated, MDX enables you to combine terse markdown syntax for your content with the power of JSX components. So you can import a JSX component and render it within the markdown itself. It's the best of both worlds.

<strong>
  "How is this different from <a href="https://github.com/hashicorp/next-mdx-remote"><code>next-mdx-remote</code></a>?"
</strong>

mdx-bundler actually bundles dependencies of your MDX files. For example, this won't work with next-mdx-remote, but it will with mdx-bundler:

---
title: Example Post
published: 2021-02-13
description: This is some description
---

# Wahoo

import Demo from './demo'

Here's a **neat** demo:

<Demo />

next-mdx-remote chokes on that import because it's not a bundler, it's just a compiler. mdx-bundler is an MDX compiler and bundler. That's the difference.

<strong>
  "How is this different from the mdx plugins for webpack or rollup?"
</strong>

Those tools are intended to be run "at build time" and then you deploy the built version of your files. This means if you have some content in MDX and want to make a typo change, you have to rebuild and redeploy the whole site. This also means that every MDX page you add to your site will increase your build-times, so it doesn't scale all that well.

mdx-bundler can definitely be used at build-time, but it's more powerfully used as a runtime bundler. A common use case is to have a route for your MDX content and when that request comes in, you load the MDX content and hand that off to mdx-bundler for bundling. This means that mdx-bundler is infinitely scalable. Your build won't be any longer regardless of how much MDX content you have. Also, mdx-bundler is quite fast, but to make this on-demand bundling even faster, you can use appropriate cache headers to avoid unnecessary re-bundling.

Webpack/rollup/etc also require that all your MDX files are on the local filesystem to work. If you want to store your MDX content in a separate repo or CMS, you're kinda out of luck or have to do some build-time gymnastics to get the files in place for the build.

With mdx-bundler, it doesn't matter where your MDX content comes from, you can bundle files from anywhere, you're just responsible for getting the content into memory and then you hand that off to mdx-bundler for bundling.

<strong>
  "Does this work with Remix/Gatsby/Next/CRA/etc?"
</strong>

Totally. It works with any of those tools. Depending on whether your meta-framework supports server-side rendering, you'll implement it differently. You might decide to go with a built-time approach (for Gatsby/CRA), but as mentioned, the true power of mdx-bundler comes in the form of on-demand bundling. So it's best suited for SSR frameworks like Remix/Next.

<strong>
  "Can I use this other JSX libraries other than React?"
</strong>

Yes! If JSX runtime you want to use is mentioned here - https://mdxjs.com/docs/getting-started/#jsx, it's guaranteed to work. Libraries, such as hono which has react compatible API also works. Check to Other JSX runtimes to get started.

<strong>
  "Why the dodo bird emoji? 🦤"
</strong>

Why not?

<strong>
  "Why is esbuild a peer dependency?"
</strong>

esbuild provides a service written in GO that it interacts with. Only one instance of this service can run at a time and it must have an identical version to the npm package. If it was a hard dependency you would only be able to use the esbuild version mdx-bundler uses.

Table of Contents

• Installation
• Usage
• Options
• Returns
• Types
• Component Substitution
• Frontmatter and const
• Accessing named exports
• Image Bundling
• Bundling a file.
• Custom Components in Downstream Files
• Known Issues
• Inspiration
• Other Solutions
• Issues
• 🐛 Bugs
• 💡 Feature Requests
• Contributors ✨
• LICENSE

Installation

This module is distributed via [npm][npm] which is bundled with [node][node] and should be installed as one of your project's dependencies:

npm install --save mdx-bundler esbuild

One of mdx-bundler's dependencies requires a working [node-gyp][node-gyp] setup to be able to install correctly.

Usage

import {bundleMDX} from 'mdx-bundler'

const mdxSource = `
---
title: Example Post
published: 2021-02-13
description: This is some description
---

# Wahoo

import Demo from './demo'

Here's a **neat** demo:

<Demo />
`.trim()

const result = await bundleMDX({
  source: mdxSource,
  files: {
    './demo.tsx': `
import * as React from 'react'

function Demo() {
  return 

Neat demo!


}

export default Demo
    `,
  },
})

const {code, frontmatter} = result

From there, you send the code to your client, and then:

import * as React from 'react'
import {getMDXComponent} from 'mdx-bundler/client'

function Post({code, frontmatter}) {
  // it's generally a good idea to memoize this function call to
  // avoid re-creating the component every render.
  const Component = React.useMemo(() => getMDXComponent(code), [code])
  return (
    <>
      <header>
        <h1>{frontmatter.title}</h1>


{frontmatter.description}


      </header>
      <main>
        <Component />
      </main>
    </>
  )
}

Ultimately, this gets rendered (basically):

<header>
  <h1>This is the title</h1>


This is some description


</header>
<main>



    <h1>Wahoo</h1>



Here's a <strong>neat</strong> demo:





Neat demo!





</main>

Options

source

The string source of your MDX.

Can not be set if file is set

file

The path to the file on your disk with the MDX in. You will probably want to set cwd as well.

Can not be set if source is set

files

The files config is an object of all the files you're bundling. The key is the path to the file (relative to the MDX source) and the value is the string of the file source code. You could get these from the filesystem or from a remote database. If your MDX doesn't reference other files (or only imports things from node_modules), then you can omit this entirely.

mdxOptions

This allows you to modify the built-in MDX configuration (passed to @mdx-js/esbuild). This can be helpful for specifying your own remarkPlugins/rehypePlugins.

The function is passed the default mdxOptions and the frontmatter.

bundleMDX({
  source: mdxSource,
  mdxOptions(options, frontmatter) {
    // this is the recommended way to add custom remark/rehype plugins:
    // The syntax might look weird, but it protects you in case we add/remove
    // plugins in the future.
    options.remarkPlugins = [...(options.remarkPlugins ?? []), myRemarkPlugin]
    options.rehypePlugins = [...(options.rehypePlugins ?? []), myRehypePlugin]

    return options
  },
})

esbuildOptions

You can customize any of esbuild options with the option esbuildOptions. This takes a function which is passed the default esbuild options and the frontmatter and expects an options object to be returned.

bundleMDX({
  source: mdxSource,
  esbuildOptions(options, frontmatter) {
    options.minify = false
    options.target = [
      'es2020',
      'chrome58',
      'firefox57',
      'safari11',
      'edge16',
      'node12',
    ]

    return options
  },
})

More information on the available options can be found in the esbuild documentation.

It's recommended to use this feature to configure the target to your desired output, otherwise, esbuild defaults to esnext which is to say that it doesn't compile any standardized features so it's possible users of older browsers will experience errors.

globals

This tells esbuild that a given module is externally available. For example, if your MDX file uses the d3 library and you're already using the d3 library in your app then you'll end up shipping d3 to the user twice (once for your app and once for this MDX component). This is wasteful and you'd be better off just telling esbuild to not bundle d3 and you can pass it to the component yourself when you call getMDXComponent.

Global external configuration options: https://www.npmjs.com/package/@fal-works/esbuild-plugin-global-externals

Here's an example:

// server-side or build-time code that runs in Node:
import {bundleMDX} from 'mdx-bundler'

const mdxSource = `
# This is the title

import leftPad from 'left-pad'



{leftPad("Neat demo!", 12, '!')}


`.trim()

const result = await bundleMDX({
  source: mdxSource,
  // NOTE: this is *only* necessary if you want to share deps between your MDX
  // file bundle and the host app. Otherwise, all deps will just be bundled.
  // So it'll work either way, this is just an optimization to avoid sending
  // multiple copies of the same library to your users.
  globals: {'left-pad': 'myLeftPad'},
})

// server-rendered and/or client-side code that can run in the browser or Node:
import * as React from 'react'
import leftPad from 'left-pad'
import {getMDXComponent} from 'mdx-bundler/client'

function MDXPage({code}: {code: string}) {
  const Component = React.useMemo(
    () => getMDXComponent(result.code, {myLeftPad: leftPad}),
    [result.code, leftPad],
  )
  return (
    <main>
      <Component />
    </main>
  )
}

cwd

Setting cwd (current working directory) to a directory will allow esbuild to resolve imports. This directory could be the directory the mdx content was read from or a directory that off-disk mdx should be run in.

content/pages/demo.tsx

import * as React from 'react'

function Demo() {
  return 

Neat demo!


}

export default Demo

src/build.ts

import {bundleMDX} from 'mdx-bundler'

const mdxSource = `
---
title: Example Post
published: 2021-02-13
description: This is some description
---

# Wahoo

import Demo from './demo'

Here's a **neat** demo:

<Demo />
`.trim()

const result = await bundleMDX({
  source: mdxSource,
  cwd: '/users/you/site/_content/pages',
})

const {code, frontmatter} = result

grayMatterOptions

This allows you to configure the gray-matter options.

Your function is passed the current gray-matter configuration for you to modify. Return your modified configuration object for gray matter.

bundleMDX({
  grayMatterOptions: options => {
    options.excerpt = true

    return options
  },
})

bundleDirectory & bundlePath

This allows you to set the output directory for the bundle and the public URL to the directory. If one option is set the other must be as well.

The Javascript bundle is not written to this directory and is still returned as a string from bundleMDX.

This feature is best used with tweaks to mdxOptions and esbuildOptions. In the example below .png files are written to the disk and then s