MDX Loader treats .md files like markdown even when extension is configured to load them as MDX

[joostdecock]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

@mdx-js/loader 2.3.0 (most recent)

Link to runnable example

https://github.com/joostdecock/mdxmd

Steps to reproduce

The repo linked above is a minimal reproduction. Steps to run it:

git clone git@github.com:joostdecock/mdxmd.git
cd mdxmd
npm i
npm run dev

Now open your browser at http://localhost:3000 and you will see this:

Expected behavior

The next config is as follows:

const configuration = {
  pageExtensions: ["mjs"],
  webpack(config, options) {
    config.module.rules.push({
      test: /\.mdx?$/,
      use: [
        options.defaultLoaders.babel,
        {
          loader: "@mdx-js/loader",
          /** @type {import('@mdx-js/loader').Options} */
          options: {
            /* jsxImportSource: …, otherOptions… */
          },
        },
      ],
    });

    return config;
  },
};

Note the the test which configures both .md and .mdx extensions to be treated the same:

test: /\.mdx?$/,

When files are loaded like this:

import MD from '../mdx/example.md'
import MDX from '../mdx/example.mdx'

I would expect both of them to be treated as MDX.

Actual behavior

When files are loaded like this:

import MD from '../mdx/example.md'
import MDX from '../mdx/example.mdx'

the .md file is treated as markdown whereas the .mdx file is treated as MDX.

Runtime

Node v16

Package manager

npm v8

OS

Linux

Build and bundle tools

webpack

[joostdecock]

The issue template tends to make it easy to fall into the XY-problem trap, so to be clear, let me state what I would like to do:

I have a bunch of .md files with MDX content. I want to load those in NextJS as MDX. But they get loaded as Markdown.
If I rename the file to .mdx it works as expected, with the exact same config.

Renaming all files is something I'd rather avoid. Instead, I'd like to say: *Hey, treat these .md files as .mdx files, but configuring extension accordingly does not seem to do the trick.

[ChristianMurphy]

@joostdecock this is the expected behavior.
MDX can process plain markdown or MDX.
How it processes is configured by the format option. https://mdxjs.com/packages/mdx/#optionsformat
You have configured your parser (implicitly) to detect which will look at the file type and choose which format to use based off the extension.
If you would like everything to be treated as MDX, set the format option to mdx.

---

though taking a few steps back, it could be an even better idea to use the correct extension in the first place 🙂

[joostdecock]

@ChristianMurphy Oh wow thank you so much because I was starting to go insane here :)

I don't know if I'm the only one dumb enough not to figure this out, but perhaps a note in the docs would help?

To be fair, I was initially using @next/mdx which handles the webpack config. The documentation (linked to from the MDX loader docs) states:

Optionally you can match other file extensions for MDX compilation, by default only .mdx is supported

// next.config.js
const withMDX = require('@next/mdx')({
extension: /.(md|mdx)$/,
})
module.exports = withMDX()

Now I am not a native speaker, but to me reading match other file extensions for MDX compilation sounds like this is all I need to compile .md files as MDX.

Not complaining. I'm very appreciative of all the great work and prompt feedback. I'm merely pointing out that it's not that I didn't bother to read the docs. It's that what was written in them made me feel it should work 🤷

[ChristianMurphy]

Optionally you can match other file extensions for MDX compilation, by default only .mdx is supported

to me reading match other file extensions for MDX compilation sounds like this is all I need to compile .md files as MDX.

I'd agree that the Next.js documentation worded in a way that can be misinterpreted, would you be interested in opening a PR to Next.js to clarify their documentation?

[joostdecock]

@ChristianMurphy Already on it!

[joostdecock]

vercel/next.js#49785