mdx-deck start error with 'TypeError: Cannot read property 'internal' of null'

[jackleslie]

I'm creating a deck using the example from Zeit's now-examples repository.

I can start a development server correctly and see the success: Building development bundle output from Gatsby, however as soon as I change a file the development server crashes with this error:

  TypeError: Cannot read property 'internal' of null

  - gen-mdx.js:48 payloadCacheKey
    [javascript-slides]/[gatsby-plugin-mdx]/utils/gen-mdx.js:48:46

  - gen-mdx.js:51 genMDX
    [javascript-slides]/[gatsby-plugin-mdx]/utils/gen-mdx.js:51:43

  - source-nodes.js:108 processMDX
    [javascript-slides]/[gatsby-plugin-mdx]/gatsby/source-nodes.js:108:5

  - source-nodes.js:158 resolve
    [javascript-slides]/[gatsby-plugin-mdx]/gatsby/source-nodes.js:158:35

  - gatsby-node.js:40 
    [javascript-slides]/[gatsby-theme-mdx-deck]/gatsby-node.js:40:24

  - gatsby-node.js:47 resolveTitle
    [javascript-slides]/[gatsby-theme-mdx-deck]/gatsby-node.js:47:60


not finished createPages - 0.077s


——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————
3 pages                                                                    In Progress                                                                    mdx-deck
Error: Command failed with exit code 1 (EPERM): gatsby develop --host localhost --port 8000 --open
    at makeError (/Users/jackleslie/Desktop/Talks/javascript-slides/node_modules/execa/lib/error.js:59:11)
    at handlePromise (/Users/jackleslie/Desktop/Talks/javascript-slides/node_modules/execa/index.js:112:26)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

Here's my project for reference, nothing much to see at the moment

[leveneg]

+1

[LukasPolak]

+1

[pedronauck]

Same here 😕

[leveneg]

this seems like a dup of #595

[jackleslie]

@leveneg yeah you’re right - I didn’t read down far enough in that issue initially to realise it was the same thing, my bad!

Will keep this open for visibility.

[karlhorky]

@jxnblk opened a PR to pin the Gatsby version to fix this here: #603

[therealklanni]

Fix this now, in your own project (if you use yarn):

"resolutions": {
  "mdx-deck/gatsby": "2.18.4",
  "mdx-deck/gatsby-plugin-compile-es6-packages": "2.1.0"
}

Add the above to your package.json and run yarn to install the working package versions.

Thanks to @karlhorky #603

---

Also try

"mdx-deck/**/gatsby": "2.18.4"

via @mlouage https://github.com/jxnblk/mdx-deck/issues/598#issuecomment-570532764

[hasparus]

Thank you @therealklanni

[mattfwood]

I've been running into this issue constantly on 3.0.13. Basically if I save any markdown, the server crashes.

I tried the solution by @therealklanni but didn't have any luck.

Here's the source line:

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-mdx/utils/gen-mdx.js#L48

It looks like between saves node is returned as null.

The gatsby-plugin-mdx version is 1.0.64, which is the latest at the time of writing this.

Is there a previous version that didn't have this issue?

[mlouage]

Same here, the fix does not work for "mdx-deck": "^3.0.13"

I added the following and it worked

"resolutions": {
"mdx-deck/**/gatsby": "2.18.4"
},

I'm using yarn.

[nkuehn]

Does anybody know whether there is an issue tracking the problem in gatsby-plugin-mdx? Or at least have a good description that it's not mdx-deck calling something in the wrong way so there's better backing to file a new one in the gatsby project?

I'm asking because locking down the version or version resolution doesn't work for me. My deck is part of a bigger monorepository with other gatsby implementations that can't be arbitrarily locked down to older versions.

[leveneg]

@nkuehn not that I'm aware of. That's something that should likely be done, even if it's just pasting the stack trace.

[karlhorky]

@nkuehn does pinning to the older version like in the code block below not work? Or do you not use Yarn?

Yarn Resolutions should only pin the version of gatsby that is a direct or transient dependency of mdx-deck, which wouldn't impact the other versions of Gatsby that are required by other packages in your monorepo.

"resolutions": {
  "mdx-deck/**/gatsby": "2.18.4"
},

I conclude this this from the following text from the original Yarn Resolutions RFC:

• a/**/b denotes all the nested dependencies b of the project's dependency a.

[nkuehn]

Hi @karlhorky I am using yarn, but I use mdx-deck as a gatsby plugin so gatsby is not a transient but a direct dependency. We're working with fixed dependencies and the renovator bot so i'll have to find out how to tell renovator to not try updating gatsby in that specific package etc.

"Just pasting" and adjusting to the plugin did not work, it caused other resolution issues that made yarn abort with an error. I'll try again to make sure I wasn't messing things up.

I think it would work but the chain of follow-up patching illustrates my point that fixing the version is helpful but not really a long-term solution that works for all mdx-deck use cases.

[karlhorky]

I use mdx-deck as a gatsby plugin

Ah, ok. I'm not familiar with these newer use cases.

Do you mean that you use it via the gatsby-theme-mdx-deck package?

[nkuehn]

Yes, that's what I do. It turned out to be more stable and flexible, for example I can configure a path prefix to deploy the presentation as github pages or in a domain containing many other pieces of content.

[jackleslie]

  "resolutions": {
    "mdx-deck/**/gatsby": "2.18.4"
  }

This worked for me, thanks @mlouage @therealklanni

[trevordmiller]

I would suggest keeping this issue open until a fix is in place in the repo itself, not specific to pinning a sub-dependency version and using yarn. Looks like https://github.com/jxnblk/mdx-deck/pull/603 fixes it. Also might be a duplicate of https://github.com/jxnblk/mdx-deck/issues/595.