When is the `files` option really required?

[andyjakubowski]

First off, thanks for the amazing work you’ve put into this. mdx-bundler makes the authoring experience so much better.

I’d like to better understand when I need to pass in the files option to bundleMDX.

I use mdx-bundler when I statically generate my site at build time with Next.js. The MDX files are stored locally in the project in /posts. The MDX files import components from a local folder and from installed packages, like this:

import JustAnotherComponent from '../components/just-another-component.js';
import { CodePen } from 'mdx-embed';

Welcome to just another post. Here’s JustAnotherComponent:

<JustAnotherComponent />
<CodePen codePenId="PNaGbb" />

The readme for files says you can omit the option if you only import from node_modules. That would be the CodePen case in the example above. But, I also import JustAnotherComponent from the local filesystem.

I’m currently not passing the files option at all, and it still works. So I wonder if I’m doing something wrong and it will blow up later, or can esbuild handle resolving local filesystem imports like this at build time?

I saw #29, but the PR implemented there implied you’d need the cwd option instead of files, whereas I’m not using either here.

[kettanaito]

I'm wondering about this as well. I can assume that the files option allows you to override the content (and import path) of the file your MDX files may import. For example, you can resolve the file import to literally any content string even if the file doesn't exist in the file-system. Perhaps that's partially the intention, as you can resolve the file content from a remote server, for instance, not having to deal with merging/deploying that file if you need to make a quick fix there.