Does not yet support Next.js Version 13

[maximilianschmitt]

I've noticed that next-mdx-remote doesn't work with Next.js 13.

To reproduce the issue, I tried running the official example with-mdx-remote using Next.js 13 and it doesn't work. Trying to load the example post, I get the following error:

How to reproduce

• Apply this commit to update run the official example
• Run yarn dev
• Go to http://localhost:3000/posts/example-post

In my own project, I'm getting a similar error relating to imports of components, so I assume the issue might be related to changes in Next.js' bundler or build system.

I don't get the error if I run the tests in this repo (hashicorp/next-mdx-remote) with Next.js 13. For me that's another hint that the error might be related to bundling, since in this repo the test doesn't import next-mdx-remote through node_modules (see

next-mdx-remote/__tests__/fixtures/basic/pages/index.jsx

Lines 5 to 6 in f5b0e74

	import { serialize } from '../../../../serialize'
	import { MDXRemote } from '../../../../'

)

Compiled Output

Here is the compiled output of node_modules/next-mdx-remote/index.js:

import React, { useState, useEffect, useMemo } from 'react';
import { jsxRuntime } from './jsx-runtime.cjs';
import * as mdx from '@mdx-js/react';

if (typeof window !== 'undefined') {
  window.requestIdleCallback =
    window.requestIdleCallback ||
    function (cb) {
      var start = Date.now();
      return setTimeout(function () {
        cb({
          didTimeout: false,
          timeRemaining: function () {
            return Math.max(0, 50 - (Date.now() - start))
          },
        });
      }, 1)
    };

  window.cancelIdleCallback =
    window.cancelIdleCallback ||
    function (id) {
      clearTimeout(id);
    };
}

/**
 * Renders compiled source from next-mdx-remote/serialize.
 */
function MDXRemote({ compiledSource, frontmatter, scope, components = {}, lazy, }) {
    const [isReadyToRender, setIsReadyToRender] = useState(!lazy || typeof window === 'undefined');
    // if we're on the client side and `lazy` is set to true, we hydrate the
    // mdx content inside requestIdleCallback, allowing the page to get to
    // interactive quicker, but the mdx content to hydrate slower.
    useEffect(() => {
        if (lazy) {
            const handle = window.requestIdleCallback(() => {
                setIsReadyToRender(true);
            });
            return () => window.cancelIdleCallback(handle);
        }
    }, []);
    const Content = useMemo(() => {
        // if we're ready to render, we can assemble the component tree and let React do its thing
        // first we set up the scope which has to include the mdx custom
        // create element function as well as any components we're using
        const fullScope = Object.assign({ opts: { ...mdx, ...jsxRuntime } }, { frontmatter }, scope);
        const keys = Object.keys(fullScope);
        const values = Object.values(fullScope);
        // now we eval the source code using a function constructor
        // in order for this to work we need to have React, the mdx createElement,
        // and all our components in scope for the function, which is the case here
        // we pass the names (via keys) in as the function's args, and execute the
        // function with the actual values.
        const hydrateFn = Reflect.construct(Function, keys.concat(`${compiledSource}`));
        return hydrateFn.apply(hydrateFn, values).default;
    }, [scope, compiledSource]);
    if (!isReadyToRender) {
        // If we're not ready to render, return an empty div to preserve SSR'd markup
        return (React.createElement("div", { dangerouslySetInnerHTML: { __html: '' }, suppressHydrationWarning: true }));
    }
    // wrapping the content with MDXProvider will allow us to customize the standard
    // markdown components (such as "h1" or "a") with the "components" object
    const content = (React.createElement(mdx.MDXProvider, { components: components },
        React.createElement(Content, null)));
    // If lazy = true, we need to render a wrapping div to preserve the same markup structure that was SSR'd
    return lazy ? React.createElement("div", null, content) : content;
}

export { MDXRemote };

[BRKalow]

Thanks for the report. We haven't had the opportunity to test it out with v13 yet, but we'll take a look at this soon!

[AdamLeBlanc]

I'm just going to piggyback off of this issue rather than creating a new one (can if the author prefers).

There seems to be a separate issue when server/static rendering with Next 13.

export default async function Post(props: Props) {
  const source = await serialize("Some **mdx**");
  return (
    <div>
      <MDXRemote {...source} />
    </div>
  );
}

will result in the following error

Warning: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/link/invalid-hook-call for tips about how to debug and fix this problem.
TypeError: Cannot read properties of null (reading 'useState')

However, wrapping the component to force it to client render like so

"use client";

import { MDXRemote, MDXRemoteProps } from "next-mdx-remote";

export default function MDXRemoteWrapper(props: MDXRemoteProps) {
  return <MDXRemote {...props} />;
}

It seems to "solve" the issue.

I'm too tired to look into it anymore tonight but may poke around tomorrow if no one else is looking into it. But it seems like wrapping it like this is needed without some reorganization of the project, so the MDXRemote component gets loaded in with the "use client" directive.

[jmikrut]

Hey all,

In addition to the above, I'm seeing the following build errors while trying to import { serialize } from 'next-mdx-remote/serialize':

export 'serialize' (reexported as 'serialize') was not found in './dist/serialize.js' (module has no exports)

This only happens when we try and enable the runtime: 'experimental-edge' Next config property though.

Thought we'd keep all the Next 13 issues in the same place if possible so just tacking on here.

[Frostbourn]

Same issue here.
TypeError: Cannot read properties of undefined (reading 'default')

[BRKalow]

If anyone is willing to make a codesandbox or minimal reproduction repo, that would be very helpful!

[Frostbourn]

Here it is: test-app

Thank you!

[jescalan]

Just a small note here - we are aware on the nextjs team that the app directory doesn't yet support mdx-remote. We have it on our roadmap to address this, but aren't quite there yet. We're still working on fixing critical bugs and stabilizing it right now, as it's still beta.

I'll drop updates here when we start working on this!

[mikewheaton]

For anyone else who is blocked by this, you can create a wrapper component (outside of the /app folder) like so:

"use client";

import { MDXRemote, MDXRemoteProps } from "next-mdx-remote";

interface MDXContentProps {
  source: MDXRemoteProps;
}

export default function MDXContent({ source }: MDXContentProps) {
  return <MDXRemote {...source} />;
}

And then within the /app folder, in a page.tsx file:

// This is the wrapper component above.
import MDXContent from "components/MDXContent";
import { serialize } from "next-mdx-remote/serialize";
...
const source = await serialize(article.content);
...
<MDXContent source={source} />

The "use client" directive (see docs) makes this a client component so that it has access to local state. I haven't done any extensive testing here, but I believe the tradeoff is that next-mdx-remote will be included in the JS bundle sent to the client and that the work of translating will take place there, even if the app is otherwise statically rendered.

[AlanMorel]

I can't even get it to work using the workarounds pasted above.

When I try, I get Error: Objects are not valid as a React child (found: [object Promise]). If you meant to render a collection of children, use an array instead..

Does anybody already have a repo they're willing to share that works (Next 13 + app directory + MDX), even if its using a workaround?

[rimzzlabs]

For anyone else who is blocked by this, you can create a wrapper component (outside of the /app folder) like so:

"use client";

import { MDXRemote, MDXRemoteProps } from "next-mdx-remote";

interface MDXContentProps {
  source: MDXRemoteProps;
}

export default function MDXContent({ source }: MDXContentProps) {
  return <MDXRemote {...source} />;
}

And then within the /app folder, in a page.tsx file:

// This is the wrapper component above.
import MDXContent from "components/MDXContent";
import { serialize } from "next-mdx-remote/serialize";
...
const source = await serialize(article.content);
...
<MDXContent source={source} />

The "use client" directive (see docs) makes this a client component so that it has access to local state. I haven't done any extensive testing here, but I believe the tradeoff is that next-mdx-remote will be included in the JS bundle sent to the client and that the work of translating will take place there, even if the app is otherwise statically rendered.

I still got the Error: Unsupported Server Component type: undefined

[ekafyi]

For anyone else who is blocked by this, you can create a wrapper component (outside of the /app folder) like so [...]

This worked for me (new appDir with SSG), thanks @mikewheaton !

[willin]

For anyone else who is blocked by this, you can create a wrapper component (outside of the /app folder) like so:

"use client";

import { MDXRemote, MDXRemoteProps } from "next-mdx-remote";

interface MDXContentProps {
  source: MDXRemoteProps;
}

export default function MDXContent({ source }: MDXContentProps) {
  return <MDXRemote {...source} />;
}

And then within the /app folder, in a page.tsx file:

// This is the wrapper component above.
import MDXContent from "components/MDXContent";
import { serialize } from "next-mdx-remote/serialize";
...
const source = await serialize(article.content);
...
<MDXContent source={source} />

The "use client" directive (see docs) makes this a client component so that it has access to local state. I haven't done any extensive testing here, but I believe the tradeoff is that next-mdx-remote will be included in the JS bundle sent to the client and that the work of translating will take place there, even if the app is otherwise statically rendered.

For anyone else who is blocked by this, you can create a wrapper component (outside of the /app folder) like so:

"use client";

import { MDXRemote, MDXRemoteProps } from "next-mdx-remote";

interface MDXContentProps {
  source: MDXRemoteProps;
}

export default function MDXContent({ source }: MDXContentProps) {
  return <MDXRemote {...source} />;
}

And then within the /app folder, in a page.tsx file:

// This is the wrapper component above.
import MDXContent from "components/MDXContent";
import { serialize } from "next-mdx-remote/serialize";
...
const source = await serialize(article.content);
...
<MDXContent source={source} />

The "use client" directive (see docs) makes this a client component so that it has access to local state. I haven't done any extensive testing here, but I believe the tradeoff is that next-mdx-remote will be included in the JS bundle sent to the client and that the work of translating will take place there, even if the app is otherwise statically rendered.

I still got the Error: Unsupported Server Component type: undefined

undefined useState too.

[Tylopilus]

I am not able to use MDXContent in a clientcomp. I am getting TypeError: _jsxDEV is not a function as an error.

impl code:

// Article.tsx
'use client';

import { MDXRemote, MDXRemoteProps } from 'next-mdx-remote';

export function Article({ content }: { content: MDXRemoteProps }) {
  return <MDXRemote {...content} />;
}

// page.tsx
import { serialize } from 'next-mdx-remote/serialize';
import { Article } from '../../../components/Article';
import { getPostBySlug } from '../../../utils/markdownHelper';
type PageProps = {
  params: { post: string };
  searchParams?: { [key: string]: string | string[] | undefined };
};
export default async function Page({ params }: PageProps) {
  const { content } = getPostBySlug(params.post);
  const mdx = await serialize(content);
  return (
    <div>
      <Article content={mdx} />
    </div>
  );
}

using node 18 w/ next@13.0.6 and next-mdx-remote@^4.2.0

[typeofweb]

I am not able to use MDXContent in a clientcomp. I am getting TypeError: _jsxDEV is not a function as an error.

It works if you force-downgrade @mdx-js to 2.1.5:

"resolutions": {
	"@mdx-js/mdx": "2.1.5",
	"@mdx-js/react": "2.1.5"
},

[Tylopilus]

Can confirm this works.

For the npm users, the key here is "overrides"

 "overrides": {
    "@mdx-js/mdx": "2.1.5",
    "@mdx-js/react": "2.1.5"
  }

[j471n]

It works if you force-downgrade @mdx-js to 2.1.5:

I can confirm that it works. But I have one question for you @mmiszy. Doing this will break anything in future if you are using Next.js v13? The point is what are the stakes if we use version 2.1.5.

[typeofweb]

@j471n sadly, I have no clue. Let's see if the maintainers reply.

[moelzanaty3]

I am not able to use MDXContent in a clientcomp. I am getting TypeError: _jsxDEV is not a function as an error.

It works if you force-downgrade @mdx-js to 2.1.5:

"resolutions": {
	"@mdx-js/mdx": "2.1.5",
	"@mdx-js/react": "2.1.5"
},

thanks, @mmiszy for your temp solution, as maybe someone does not know about selective dependency resolutions and did this workaround, it might produce Certain edge cases that may not work properly since this is a fairly new feature. so please add a TODO: in your code base to upgrade in the future one maintainer adds a hotfix.

worth reading

• How do you override nested dependencies with yarn?
• How do I override nested NPM dependency versions?

[imtsuki]

There is a better temporary solution without the need to downgrade @mdx-js/* to 2.1.5. Just add development: false to the mdxOptions argument within the serialize() call:

 const mdxSource = await serialize(content, {
   mdxOptions: {
     remarkPlugins: [],
     rehypePlugins: [],
+    development: false,
   },
});

In mdx-js/mdx#2045, compiled MDX source will use jsxDEV for rendering in development mode, while in production mode it uses jsx and jsxs. jsxDEV should be imported from react/jsx-dev-runtime, but it is not exported by src/jsx-runtime.cjs. This causes the TypeError: _jsxDEV is not a function error.

[imtsuki]

I opened a PR (#323) to fix this issue. Before it gets merged, you can use the temporary workaround.

[YannHulot]

I downgraded to

...
"next-mdx-remote": "^4.2.0",
...

and that fixed the issue.

[ramblehead]

It looks there is an entanglement with next-remote-watch - at least in my settings.

In package.json:

"scripts": {
  "dev": "next-remote-watch ../content/pages ./public/static/locales",
}

Running yarn dev (above script) produces TypeError: _jsx is not a function. However, running yarn next dev works as expected with the latest versions of nextjs and next-mdx-remote.

[BRKalow]

Thanks y'all, I'll take a look at some of the reported issues with 4.2.1. Note that the previous workaround should likely be removed, and you might need to do a full re-install of next-mdx-remote:

npm uninstall next-mdx-remote && npm install next-mdx-remote

(or whatever the equivalent would be for your package manager of choice)

[c0ntradicti0n]

Hm, after combining all workarounds it worked.

I got:

updated to version 4.2.1

      const serializedResult = await serialize(content, {
           mdxOptions: {
    development: process.env.NODE_ENV !== 'production',
  }})

    "@mdx-js/mdx": "2.2.1",
    "@mdx-js/react": "2.2.1",

(overrides had no effect).

So to remove the previous workaround was not successful.

[don-esteban]

This is a working configuration. Just did npm install on a fresh clone and npm run dev. It runs on Vercel too. No need for serialize/mdxOptions

// package.json
{
  ...
  },
  "dependencies": {
    "@fortawesome/fontawesome-svg-core": "^6.2.1",
    "@fortawesome/free-regular-svg-icons": "^6.2.1",
    "@fortawesome/free-solid-svg-icons": "^6.2.1",
    "@fortawesome/react-fontawesome": "^0.2.0",
    "next": "^13.0.7",
    "react": "18.2.0",
    "react-dom": "18.2.0"
  },
  "devDependencies": {
    "eslint": "^8.29.0",
    "eslint-config-next": "^13.0.7",
    "glob": "^8.0.3",
    "gray-matter": "^4.0.3",
    "next-mdx-remote": "^4.2.1",
    "sass": "^1.55.0",
    "yamljs": "^0.3.0"
  }
}

// index.js
...
<MDXContent>{description}</MDXContent>
...
export async function getStaticProps(context) {
  ...
  description: data.description ? await serialize(data.description) : null
  ...

// MDX Content Component
import { MDXRemote } from 'next-mdx-remote'
import LinkOrA from './link-or-a'

const components = {
  a: (props) => <LinkOrA {...props} />
}

export default function MDXContent({ children }) {
  if (children) {
    return (
      <MDXRemote {...children} components={components} />
      )
  }
  return null
}

[c0ntradicti0n]

Using SSR, then it's not needed as it turned out. But if you use serialize on client side, then the mdxOptions is needed and have to be switched depending on dev and prod mode.

import Head from 'next/head'
import {useEffect, useState} from 'react'
import {MDXRemote} from 'next-mdx-remote'
import {serialize} from 'next-mdx-remote/serialize'
import {console} from "next/dist/compiled/@edge-runtime/primitives/console";


const components = {
    a: (props) => <a href={props.href}> {props.children} </a>
}

export async function getStaticProps(context) {

    return {
        props: {description: await serialize("[WIKIPEDIA](http://wikipedia.org)")}

    }
}

function MDXContent({children, description}) {

    const [x, sX] = useState(null)
    useEffect(() => {
        ;(async () => {
            if (children)
                sX(await serialize(children, {mdxOptions: {development: true}}))
        })()
    }, [children])

    if (description) {
        return (
            <MDXRemote {...description} components={components}/>
        )
    }
    if (x) {
        return (
            <MDXRemote {...x} components={components}/>
        )
    }
    return null
}


export default function Home({description}) {

    return (
        <>
            <Head>
                <title>Create Next App</title>
                <meta name="description" content="Generated by create next app"/>
                <meta name="viewport" content="width=device-width, initial-scale=1"/>
                <link rel="icon" href="/favicon.ico"/>
            </Head>
            <MDXContent>[WIKIPEDIA](http://wikipedia.org)</MDXContent>
            <MDXContent description={description}/>
        </>
    )
}

[BRKalow]

Hey y'all, we've now get experimental support for server components, and the app directory. Take a look at the release notes & documentation and give it a try!

[pszafer]

Hi, thanks for this release!
With typing I got 2 errors while testing:
with MDXRemote:

'MDXRemote' cannot be used as a JSX component.
  Its return type 'Promise<Element>' is not a valid JSX element.
    Type 'Promise<Element>' is missing the following properties from type 'Element': type, props, key

with compileMdx:

Argument of type '{ source: string; options: { mdxOptions: {}; }; }' is not assignable to parameter of type 'MDXRemoteProps'.
  Property 'compiledSource' is missing in type '{ source: string; options: { mdxOptions: {}; }; }' but required in type 'MDXRemoteSerializeResult<Record<string, unknown>, Record<string, string>>'.

Should I create new issue or is it some error on my side?

[AlanMorel]

I am getting the same exact issues @pszafer, not an error on your side

[magoz]

I ran into the same issue and solved it using {/* @ts-expect-error Server Component */}.

It's documented on the Next 13 beta docs.

[josiahwiebe]

I'm getting a different error when trying to use next-mdx-remote/rsc:

SyntaxError: Unexpected token u in JSON at position 0
    at JSON.parse (<anonymous>)
    at parseModel (/Users/josiah/Developer/jwie.be/node_modules/next/dist/compiled/react-server-dom-webpack/client.js:40:15)
    at initializeModelChunk (/Users/josiah/Developer/jwie.be/node_modules/next/dist/compiled/react-server-dom-webpack/client.js:400:18)
    at resolveModelChunk (/Users/josiah/Developer/jwie.be/node_modules/next/dist/compiled/react-server-dom-webpack/client.js:366:5)
    at resolveModel (/Users/josiah/Developer/jwie.be/node_modules/next/dist/compiled/react-server-dom-webpack/client.js:635:5)
    at processFullRow (/Users/josiah/Developer/jwie.be/node_modules/next/dist/compiled/react-server-dom-webpack/client.js:729:9)
    at processBinaryChunk (/Users/josiah/Developer/jwie.be/node_modules/next/dist/compiled/react-server-dom-webpack/client.js:789:5)
    at progress (/Users/josiah/Developer/jwie.be/node_modules/next/dist/compiled/react-server-dom-webpack/client.js:842:5)

Probably on my end but I can't seem to figure out what might be causing it. AllI changed was upgrading next-mdx-remote to 4.3.0 and updated the component to match the docs.

Adding the {/* @ts-expect-error Server Component */} fixed my TS error but not this one.

[josiahwiebe]

A slight update to the above ☝️ I was using a custom component to wrap <MDXRemote> that looked like this:

import { MDXRemote } from 'next-mdx-remote/rsc'
import MDXComponents from '@components/mdx-components'
import type { VFileCompatible } from 'vfile'
import type { SerializeOptions } from 'next-mdx-remote/dist/types'

export function MdxContent({ source, options }: { source: VFileCompatible; options?: SerializeOptions }) {
  // @ts-expect-error Server Component
  return <MDXRemote {...source} components={MDXComponents} {...options} />
}

When I replaced that component in all of my pages with the native <MDXRemote /> component, it worked in development, but when I try to build for production I still get the same Unexpected token u in JSON... error.

[DonaldLouch]

I followed the documentation along with adding the above suggestion of //@ts-expect-error Server Component solution as I'm using TypeScript; and I'm now getting this error:

Error: Objects are not valid as a React child (found: [object Promise]). If you meant to render a collection of children, use an array instead.

My code is:

// components/MDXComp

import { MDXRemote } from 'next-mdx-remote/rsc'

import { paragraph } from "./MarkDownComponents"

const components = { 
    p: paragraph
}

export function MDXContent(props:any) {
  return (
    // @ts-expect-error Server Component
     <MDXRemote {...props} components={{ ...components, ...(props.components || {}) }}
    />
  )
}

// components/MarkDownComponents

import { Text ... } from "@chakra-ui/react"

...

const paragraph = (props: any) => (
    <Text fontSize="1.1rem" lineHeight="1.4rem">{props.children}</Text>
)

...

export { paragraph ... }

// app/page.tsx

...

import { MDXContent } from "../../../components/MDXComp";

...

export default function PAGE(props: any) {
...

    return (
        <>
             ...             
             <MDXContent source={MARKDOWNSOURCE} />
             ...             
        </>
     )      
}

Update

After some further digging I have discovered that this issue maybe caused from needing to use the 'use client' tag for ChakraUI on the majority of my pages. Linked Discussion Post

[yannickschuchmann]

It looks there is an entanglement with next-remote-watch - at least in my settings.

Same for me. next dev works. next-remote-watch produces _jsx is not a function

• next-mdx-remote 4.3.0
• next-remote-watch 2.0.0_next@13.0.2

@ramblehead Did you find a current workaround?

[ramblehead]

@ramblehead Did you find a current workaround?

@yannickschuchmann not really - just found a versions combination that seems to work for me: next-mdx-remote@4.2.1 and next-remote-watch@2.0.0

[yannickschuchmann]

Just because I have read it over this whole issue.
To help each other out with "version combinations" it's important to give precise versions. So stick to the version in your lock file.
^4.2.1 is rather a version suggestion. I had it in the past that something like a 4.2.1did work but a 4.3.0 did NOT work.

For safe & clear communication it's often better to give exact versions, especially for combinations of packages because ^4.2.1 can mean anything upwards that version.

// package.json

"next-mdx-remote": "^4.3.0",
"next-remote-watch": "^2.0.0",
// vs.
"next-mdx-remote": "^4.2.1",
"next-remote-watch": "^2.0.0",

As an example: for both variations your package manager will install the exact same packages.

Hope it's not too dramatic, I just love some helpful clarity in version talking :)

@ramblehead ofc not meant personally, maybe you even meant "4.2.1 and upwards". :)

[ramblehead]

@yannickschuchmann you are correct - I meant precise versions not ^ (“compatible with version” - e. g. future minor/patch versions).

P. S. When having a choice I tend to use yarn 3 monorepos to enforce versions consistency, yarn upgrade-interactive to update packages individually across monorepo, and yarn why to manually check consistency. That, mostly, avoids problems with ^ and ~ version prefixes.

[BRKalow]

Hi y'all,

As discussed above, we should fully support next 13 as well as the /app directory, documented here). I'm going to close this out, if you have specific issues working with next-mdx-remote and next 13 going forward, please feel free to open additional issues with reproductions. Thanks for the discussion here!