Provide a function with context for configuring MDX

[mshick]

I currently have an mdx-bundler wrapper function something like this:

    return await bundleMDXFile(filePath, {
      cwd: path.dirname(filePath),
      esbuildOptions: options => {
        options.platform = 'node'
        // Set the `outdir` to a public location for this bundle.
        options.outdir = `${process.cwd()}/public/img/${getSlug(filePath)}`
        options.loader = {
          ...options.loader,
          // Tell esbuild to use the `file` loader for pngs
          '.png': 'file',
          '.jpg': 'file'
        }
        // Set the public path to /img/about
        options.publicPath = `/img/${getSlug(filePath)}`

        // Set write to true so that esbuild will output the files.
        options.write = true

        return options
      },
      xdmOptions: options => {
        options.remarkPlugins = [
          ...(options.remarkPlugins ?? []),
          ...remarkPlugins
        ]
        options.rehypePlugins = [
          ...(options.rehypePlugins ?? []),
          ...rehypePlugins
        ]
        return options
      }
    })

You'll see that I'm able to use details from the context to configure esbuild for mdx-bundler. I use the filePath I've passed in to set an assets bundle path. I can also set the cwd to the folder of the file being bundled, allowing for easy linking of assets in the same folder as the MDX file (bundleMDXFile does it automatically). These options enable some nice functionality.

In contentlayers config I could imagine something like this:

 mdx: context => {
    return {
      cwd: path.dirname(context.filePath),
      remarkPlugins: [
        remarkGfm
      ],
      rehypePlugins: [
        [rehypePrism, { ignoreMissing: true }]
      ],
      esbuildOptions: options => {
        options.platform = 'node'
        // Set the `outdir` to a public location for this bundle.
        options.outdir = `${process.cwd()}/public/img/${getSlug(context.filepath)}`
        options.loader = {
          ...options.loader,
          // Tell esbuild to use the `file` loader for pngs
          '.png': 'file',
          '.jpg': 'file'
        }
        // Set the public path to /img/about
        options.publicPath = `/img/${getSlug(context.filepath)}`
        // Set write to true so that esbuild will output the files.
        options.write = true
        return options
      }
    }
}

[schickling]

@mshick thanks a lot for opening this issue. I'm curious to learn more about the use cases you have for this. Anything beyond #11?

[mshick]

Pretty much #11 — I'd like to be able keep my image assets next to my MDX files. Don't have any other great ideas right now!

[schickling]

Thanks for the update @mshick. I'll close this issue then in favour of #11. If you (or anyone else) has a use case for this original feature request, please comment here and we can re-open this issue. Thanks.

[mshick]

@schickling I've reviewed #11 and am actually using a similar approach already that works well enough, but doesn't address the capability I'd be able to get out of this feature, and which I think would be useful to many.

For instance, I could create a file structure like this:

-- content
---- blog-post
------ blog-post.mdx
------ cat-pic.png

Then, inside my post I could refer to my picture like so:

![A cat](./cat-pic.png)

Whereas currently, using an approach similar to what you've set up in #11 I'd have to do the following

![A cat](./blog-post/cat-pic.png)

It's a minor convenience, but would allow for some tidy file structures.

I think the proposed solution is (hopefully) low lift and opens up possibilities for other uses as well. I'm not sure how you'd surface this as a more proper contentlayer feature, but I could imagine a boolean along the lines of mdxSourceRelativeAssetPaths (quite a mouthful).

I'd be happy to take a stab at a PR for this if you're inclined.

[schickling]

This should be addressed with the 0.2.5 release. 🎉

[mshick]

@schickling I checked out the release notes and it's not clear to me whether this would handle the case I'm talking about. The issue is that the options (specifically the cwd) needs to be set to the current directory of the mdx file being processed. Unless contentlayer sets cwd itself then the only other way to handle this would be to take a function as an config option — similar to the new markdown option.

This allows you to use the mdx bundling behavior with markdown images and still have them show up in standard Markdown previews, e.g., GitHub's markdown preview. As-is, the only way to accomplish that is with a totally flat content directory which leads to some pretty gnarly results.

[gergelypap]

I'm not seeing how the 0.2.5 release addresses the problem @mshick mentioned. Currently there is no way to import components in .mdx files which are on the same level, only if the components are globally defined for the component returned by the useMDXComponent hook.

I have created #266 and found a temporary solution that might solve this issue.

[mshick]

Resolved via #270. While the implementation is not as flexible as this issue requested, it does satisfy my primary objective of getting a relative cwd, and is generally easier to use.