Mdx-deck: Dev build fails when rebuilding presentation

[proff321]

Hello! I have a very simple presentation that builds successfully the first time, but then fails to rebuild once a change is made. If you simply save the file, the build does not fail, but any modification results in the following error:

Error: Command failed with exit code 1 (EPERM): gatsby develop --host localhost --port 8000 --open
    at makeError (/app/node_modules/execa/lib/error.js:59:11)
    at handlePromise (/app/node_modules/execa/index.js:112:26)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

The code is running within a docker container. Here's the docker-compose file:

version: "3.6"
services:
    present:
        image: node
        volumes:
            - ./:/app
        ports:
            - "8000:8000"
        working_dir: /app
        entrypoint: ["npm"]
        command: ["start"]
    npm:
        image: node
        volumes:
            - ./:/app
        working_dir: /app
        entrypoint: ["npm"]
        command: ["--version"]

The present service issues the following npm command as defined in the "package.json" file:

"start": "mdx-deck presentation.mdx"

The actual presentation, saved as "presentation.mdx", is as follows:

```

Presentation Title

---

About Me

````

Here's how to setup and reproduce the issue (docker commands are run with sudo on my machine):

1. Install the framework: docker-compose run --rm npm i -D mdx-deck
2. Run the presentation service: docker-compose run --rm --service-ports present
3. The build will finish and you can see the presentation in the browser of the host
4. Save the "presentation.mdx" file without making any modifications
5. Notice that the info statement is logged, but the service remains stable
6. Modify the "presentation.mdx" file and save
7. The error mentioned above appears and the docker service dies

I noticed issue #416 which had a very similar error, but the "package-lock.json" file shows the gatsby-plugin-compile-es6-packages package as being installed at version "2.1.0".

I also tested making the changes within the container to eliminate the possibility of filesystem issues. No matter how the presentation is modified, the error still occurs.

[proff321]

You can see the repo with the above files here: https://github.com/proff321/communicating-with-postman

[donaldducky]

Same, I get the following:

Cannot read property 'internal' of null



  TypeError: Cannot read property 'internal' of null

  - gen-mdx.js:48 payloadCacheKey
    [architecture-presentation]/[gatsby-plugin-mdx]/utils/gen-mdx.js:48:46

  - gen-mdx.js:51 genMDX
    [architecture-presentation]/[gatsby-plugin-mdx]/utils/gen-mdx.js:51:43

  - source-nodes.js:108 processMDX
    [architecture-presentation]/[gatsby-plugin-mdx]/gatsby/source-nodes.js:108    :5

  - source-nodes.js:158 resolve
    [architecture-presentation]/[gatsby-plugin-mdx]/gatsby/source-nodes.js:158    :35

  - gatsby-node.js:40
    [architecture-presentation]/[gatsby-theme-mdx-deck]/gatsby-node.js:40:24

  - gatsby-node.js:47 resolveTitle
    [architecture-presentation]/[gatsby-theme-mdx-deck]/gatsby-node.js:47:60


not finished createPages - 0.074s

It looks like null is being passed as node into genMDX at some point.

[proff321]

Thank you for verifying the error. I'm trying to debug the code, but can't seem to figure out how to debug the spawned gatsby process. I've tried adding various iterations of --inspect-brk=... but the only way the execa package's childProcess.spawn(...) command will only work if you pass gatsby ... to it.

Do you have any suggestions / references on how I could debug the child process?

[proff321]

I was able to replicate the gatsby command that is spawned by the mdx-deck package. To replicate the issue:

1. Create a new folder in the root of an mdx-deck presentation project called "decks/"
2. Copy / create a presentation in that folder. It will be mounted in the correct location within the docker container.
3. Start the container (details below)
4. Modify that presentation to trigger a rebuild that will result in the error detailed above.

To make debugging easier, just add the following service to the aforementioned "docker-compose.yml" file:

    issue:
        image: node
        volumes:
            - ./:/app
            - ./decks:/app/node_modules/mdx-deck/decks
        ports:
            - "8000:8000"
            - "9229:9229"
        working_dir: /app/node_modules/mdx-deck
        entrypoint: [
            "node",
            "--inspect-brk=0.0.0.0:9229"
            ]
        command: [
            "../../node_modules/gatsby/dist/bin/gatsby.js",
            "develop",
            "--host",
            "0.0.0.0"
            ]

Use the following command to start the service with debugging enabled:

docker-compose run --rm --service-ports issue

Here's the Visual Studio Code debugger config for those who use the editor, or just need to better understand the connection configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "attach",
            "name": "Attach to gatsby",
            "address": "localhost",
            "port": 9229,
            "localRoot": "${workspaceFolder}/node_modules/mdx-deck",
            "remoteRoot": "/app/node_modules/mdx-deck"
        }
    ]
}

Please Note: The workspaceFolder is the root of a mdx-deck presentation project open in VSC, not the root of the mdx-deck package.

Now that I can successfully debug the issue, I'll start stepping through the code to understand how the node variable becomes null.

[leveneg]

git bisect seems to indicate that be543f24 introduced the issue

[therealparmesh]

I'm experiencing the same issue. It looks like a gatsby update is to blame.

[leveneg]

agreed. I've since narrowed the introduction of the bug to gatsby v2.18.5, but haven't been able to gleam anything more.

Either way, the issue does not seem to be with this project itself.

Fix here is either waiting for fix in gatsby, or reverting gatsby to 2.18.4

[hacker-DOM]

I get the same error just when building for the first time. Right above it:

Can't resolve '../../../../../../components/Demo' in '/Users/dteiml/dev/mdx-deck/node_modules/mdx-deck/.cache/caches/gatsby-plugin-mdx/mdx-scopes-dir'

File: .cache/caches/gatsby-plugin-mdx/mdx-scopes-dir/b1b1b14f25b28fd86089ac73d0597526.js

Any temporary hacks

[hacker-DOM]

Ok I solved it by removing

import Demo from './components/Demo'

## <Demo />

from the deck example in the readme.md. Bear with me I'm new here ;)

[nkuehn]

@proff321 I have the issue, too when using mdx-deck as a gatsby plugin, i.e. without the process spawning etc. That might be easier to debug. Thankful for anybody who tries and is able to file a focused issue in the gatsby project.

@hacker-DOM your issue looks unrelated to this, at least superficially.

[Nedomas]

For anybody looking for a quick workaround in the meantime, just add this to your package.json (if you're using yarn):

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

[karlhorky]

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

[trevordmiller]

Our organization is also running into this on multiple slide decks since upgrading to v3.

[privettoli]

For me the workaround was to use code-surfer-deck template

npm init code-surfer-deck my-deck

[sdalonzo]

The fix from @Nedomas above is what finally got me past this one.

[karlhorky]

If you want to upgrade to newer versions of Gatsby, then you can probably do that with #631 (3.1.0) - although be careful if you are upgrading a presentation in a monorepo (see https://github.com/jxnblk/mdx-deck/issues/640).

Maybe this issue can now be closed now.

[nkuehn]

Thanks so much @karlhorky. I can confirm doing no changes but pulling up the version resolves the issue, had no issues in the monorepo too (but it had only one package using mdx-deck).