next-mdx-remote: Breaks with latest version of remark-gfm; unhelpful error message

I’m not really sure where to file this, but:

I just started using next-mdx-remote, and everything was working fine until I added the remark-gfm plugin. This is the entire error I was getting, with no further information:

Error: [next-mdx-remote] error compiling MDX: Cannot read properties of undefined (reading ‘inTable’)

After some trial and error, I narrowed the issue down to inline code blocks – I only get the error when they’re present.

After a bit more flailing I figured out that remark-gfm released version 4.0 a few days ago, which uses remark-parser v11, while @mdx-js/mdx uses remark-parser v10. Rolling remark-gfm back to version 3.x fixed the issue.

I’ve made a minimal repro here: https://codesandbox.io/p/github/HerbCaudill/next-mdx-remote-vs-remark-gfm

I’d assume whatever needs to be fixed is not in this library but somewhere upstream; noting the solution here in case it helps anyone.

However I would suggest revisiting the error formatter in format-mdx-error.ts. For some reason it removes the stack trace before throwing MDX formatting errors, which made this very difficult to debug. I can’t imagine what the reason for doing that would be.

https://github.com/hashicorp/next-mdx-remote/blob/4b2c128f16dba9d440fe7f4931e04bb8c5d74474/src/format-mdx-error.ts#L58-L66

About this issue

  • Original URL
  • State: open
  • Created 9 months ago
  • Reactions: 43
  • Comments: 31

Commits related to this issue

Most upvoted comments

I downgraded remark-gfm from version 4.0.1 to version 3.0.1 and the error was gone

After a bit more flailing I figured out that remark-gfm released version 4.0 a few days ago, which uses remark-parser v11, while @mdx-js/mdx uses remark-parser v10. Rolling remark-gfm back to version 3.x fixed the issue.

I can confirm this solution works, good catch! The error appeared for me no matter what GFM component I used, although I first noticed after trying to add tables.

Another update from @dstaley: Canary releases of v5 are now available (check out the first comment by the bot to get the latest published canary version):

Downgrading remark-gfm to version 3 solves the problem on my end.

npm i remark-gfm@3

(For reference, I’m using Storybook with gfm in my MDX files and am following their official guide for adding gfm support)

The problem is in syntax-tree/mdast-util-gfm-table

lib/index

line 79 //this.setdata.inTable = true this.setData(‘inTable’, true)

and line 89 //this.data.inTable = undefined this.setData(‘inTable’)

the problem is because this.data is undefined while trying to update the prop inTable

this is just a fix, but it breaks the build, apparently ‘CompileContext’ is supposed to initialize this.data, but it isn’t.

Error: lib/index.js(79,8): error TS2339: Property ‘setData’ does not exist on type ‘CompileContext’. error while trying to do a pull request

Can someone give me feedback about ‘CompileContext’?

FYI this issue is already solved on all upstream libraries. Problem is, next-mdx-remote needs to update their version of said libraries, otherwise some will be using older ones whilst other newer ones and that will well… break.

@paigen11 open the “Published 1 packages” on this comment:

Inside you’ll find the version that you can add to your package.json file for next-mdx-remote (and then run npm install - or whatever your package manager install command is)

I also get this error if there is a table in the markdown.

The solution to use v3 works for me for tables and back-ticks.

I confirm having the same issue, a simple MDX with an inline code triggers the error message.

@snypiie if you’re using next-mdx-remote inside of a getStaticProps call, you’ll need to do something like this to use the remark plugin with it.

import { GetStaticPaths, GetStaticProps, GetStaticPropsContext } from "next";
import { serialize } from "next-mdx-remote/serialize";
import { MDXRemote, MDXRemoteSerializeResult } from "next-mdx-remote";
import gfm from "remark-gfm";
// other imports here to fetch blog content (irrelevant to this example)


const BlogPostPage = ({ post, mdxSource }: BlogPostPageProps) => (
  <>
      <BlogPostContent post={post}>
        <MDXRemote {...mdxSource} components={MDXComponentMap} />
      </BlogPostContent>
  </>
);

export const getStaticPaths: GetStaticPaths = async () => {
  // code to figure out blog slug URLs
};

export const getStaticProps: GetStaticProps = async ({
  params,
}: GetStaticPropsContext) => {
  const { slug } = params as Params;
  const post = await getBlogArticleFromSlug(slug);

  const mdxSource = await serialize(post.content, {
    mdxOptions: { remarkPlugins: [gfm] },
  });

  return {
    props: {
      post,
      mdxSource,
    },
  };
};

export default BlogPostPage;

The part to focus on is the mdxSource function where { remarkPlugins: [gfm] } is included. That’s what you need to add to make tables format correctly with next-mdx-remote

  const mdxSource = await serialize(post.content, {
    mdxOptions: { remarkPlugins: [gfm] },
  });

@paigen11 I’m aiming to release v5 sometime this month, and hearing that it fixes your issue is a great thing to hear! As for mdx-components.tsx, it’s not something we have specific support for. You could certainly define your components there and import them from there to pass to MDXRemote though!

@jbukuts Definitely give the canary release of v5 a shot! Should be much smoother sailing.

As an additional note for anyone trying to use @next/mdx or any other tool alongside next-mdx-remote. Most of the issues relate to conflicts in dependency versions.

For instance, when I tried using @next/mdx alongside it I hade to bump my @mdx-js/loader and @mdx-js/react versions down to match the next-mdx-remote package.json.

TL;DR Play package.json musical chairs with dependencies. Hopefully v5 fixes the chaos.

Bumping it as we still need a proper fix

I also confirm rolling back to v3.0.1 works, still we need a fix for the v4 as well 😕/

I downgraded remark-gfm from version 4.0.1 to version 3.0.1 and the error was gone

I’m using next@14.0.4 and this works for me. Thanks!

The problem is in https://github.com/syntax-tree/mdast-util-gfm-table/

lib/index

line 79 //this.setdata.inTable = true this.setData(‘inTable’, true)

and line 89 //this.data.inTable = undefined this.setData(‘inTable’)

the problem is because this.data is undefined while trying to update the prop inTable

this is just a fix, but it breaks the build, apparently ‘CompileContext’ is supposed to initialize this.data, but it isn’t.

Error: lib/index.js(79,8): error TS2339: Property ‘setData’ does not exist on type ‘CompileContext’. error while trying to do a pull request

Can someone give me feedback about ‘CompileContext’?

Is this somewhat going to be addressed by the maintainers here? As the last release was in March.