It looks like the issue here is when the package doesn't have a "default" export - see the above PR that fixed it for me. I still think this is a bug though because I could import the package without issue, it only happened when passing a string

I am getting

TypeError: Expected usable value, not `remark-breaks`
    at add (file:///Volumes/Data/Projects/bldry-website/node_modules/unified/lib/index.js:1100:15)
    at addList (file:///Volumes/Data/Projects/bldry-website/node_modules/unified/lib/index.js:1134:11)
    at Function.use (file:///Volumes/Data/Projects/bldry-website/node_modules/unified/lib/index.js:1074:9)
    at createProcessor (file:///Volumes/Data/Projects/bldry-website/node_modules/@mdx-js/mdx/lib/core.js:209:6)
    at split (file:///Volumes/Data/Projects/bldry-website/node_modules/@mdx-js/mdx/lib/util/create-format-aware-processors.js:85:37)
    at process (file:///Volumes/Data/Projects/bldry-website/node_modules/@mdx-js/mdx/lib/util/create-format-aware-processors.js:62:31)
    at Proxy.loader (file:///Volumes/Data/Projects/bldry-website/node_modules/@mdx-js/loader/lib/index.js:89:3)
    at /Volumes/Data/Projects/bldry-website/node_modules/@mdx-js/loader/index.cjs:32:26
 ⨯ unhandledRejection: [TypeError: Expected usable value, not `remark-breaks`]
 ⨯ unhandledRejection:  [TypeError: Expected usable value, not `remark-breaks`]
[TypeError: Expected usable value, not `remark-breaks`]

with

const withMDX = createMDX({
  // Add markdown plugins here, as desired
  options: {
    remarkPlugins: ['remark-breaks'],
    rehypePlugins: [['rehype-external-links', {
      target: '_blank', rel: ['noopener', 'noreferrer', 'nofollow'],
    }]],
  },
});

Along with TS errors. Did you figure it out?

When using the string format, make sure every entry in the plugin list is an array (not only when you have options)

For example, instead of this (⚠️ following code does NOT work):

const withMDX = createMDX({
    options: {
        remarkPlugins: [],
        rehypePlugins: ['rehype-slug'],
    },
})

you need to put 'rehype-slug' (the plugin string name) into an array:

const withMDX = createMDX({
    options: {
        remarkPlugins: [],
        rehypePlugins: [['rehype-slug']],
    },
})

meaning that now the plugin entry is an array (that contains the string) and the list of plugins is an array too

This typescript types error, @next/mdx is still using the types from the @mdxjs/loader (instead of defining new types in the @next/mdx/js-loader

To get rid of this error until the types are fixed, just use a typescript comment to let typescript know it should ignore the problem:

const withMDX = createMDX({
    options: {
        // @ts-ignore wrong types
        remarkPlugins: [['remark-gfm', remarkGFMOptions]],
        rehypePlugins: [],
    },
})

P.S. I have more info regarding mdx (rehype / remark) plugins in combination with turbopack and / or the mdx rust compiler in my next.js 15 mdx tutorial

It doesn't work when it's in an array form either. I've tried.

Hitting this again with the rehype-extract-excerpt package. Adding a default export to the package via a patch fixes is.

So the MDX resolution code still has a bug

I don't think this is exclusive to MDX resolution. Renaming my next config from mjs to ts revealed this error in similar packages not defining package exports correctly.

A couple more example issues referenced above 👆🏻

It doesn't work when it's in an array form either. I've tried.

Have a try with

  experimental: {
    mdxRs: true,
  }

Hello 👋

I went on a deep dive with this one in a quest to use emojis from remark-emojis. I ended up just writing a script to do it for me. Would appreciate knowing if I've missed something or followed the wrong thread. 🙂

Having a look, I found three points of failure — one is the known issue of not serializing to a string.

TLDR:

Next.js cannot work with ES6 packages that contain only 'import' pathways in their 'exports' field of their package.json. This is due to its use of 'require' in two core places.

Firstly, what do I mean by import of their exports pathway?

Node introduced multiple entry points to modules within the package.json. One reason was to ease the bridge between ES6 modules and CommonJS. We could now specify an entry point to the CommonJS modules as well as to the ES6 modules in one package. To do this, we use the 'exports' field in our package.json to specify which way 'import' should go, which way 'require' should go, and other functionalities or default settings.

Node.js Package Entry Points

More about Exports

With packages like remark-emoji, the exports field only specifies an import pathway:

"exports": {
".": {
"import": {
"types": "./index.d.ts",
"default": "./index.js"
}
}
},

If there was a default one level higher, then require would go here. Since there isn't, there is no valid entry point for require, which is correct as this package exclusively uses ES6 modules.

@wesbos, this is why you see the addition of default in your example working — because require is flowing that way.

Ok, but why isn't it happening in Next.js? Next.js seems to support ES6.

Bundling Issue with next.config.ts:

When bundling using next.config.ts (note the .ts), we encounter:

ERR_PACKAGE_PATH_NOT_EXPORTED

To replicate, simply write:

import emoji from 'remark-emoji';

This error message comes from the resolve-pkg-maps package. This package is a dependency of 'get-tsconfig', which Next.js uses during the configuration process. The error itself arises because the package being imported does not provide a valid entry point for require, which results in the error. To be clear, resolve-pkg-maps works as expected when given the correct conditionals, but somewhere along the flow it is not. The package remark-emoji is also correct, its exports key is valid. Somewhere in the flow however, its being told to use require to retrieve from remark-emoji, leading to the break, as remark-emoji does not posses and exports pathway for require.

Switching to next.config.js avoids this issue as we avoid the above flow, allowing import to work as expected.

Issue with the MDX Loader:

Within the plugin options, we can provide one of two values:

The package directly (e.g., import emoji from 'remark-emoji'; then providing emoji). This will break because we encounter the non-serializable issue since the imported plugin is a function.

Or just include the name as a string (['remark-emoji']).

The problem here is that the MDX loader (next-mdx/mdx-js-loader.js) tries to require the plugin directly, which fails because it attempts to require an ES module without a CommonJS entry point, resulting in:

TypeError: Cannot read properties of null (reading 'in')

This happens here:

getOptions found in packages/next-mdx/mdx-js-loader.js. getOptions uses require to resolve from packages, meaning it simply again can't find a pathway to import the package, resulting in 'null' which leads us to the 'in' of null problem.

Next Steps

• I'd love to know what a plugin output should look like.

• Perhaps debug the next.config.ts issue or add documentation to clarify.

• Modify the next-mdx/mdx-js-loader to support both import and require.

• Consider another way to handle this, perhaps users can have scripts or higher order comps ( idea i have not explored )

Would love to try and resolve this! Or if I've got something off, please let me know! 😄 This was fun!