Gatsby development server crashes when gatsby-remark-math has a parse error.

[tmfelwu]

Description

Whenever there is a parse error in Katex, the gatsby dev server crashes and needs to be restarted everytime.

Steps to reproduce

1. Use illegal syntax in katex.

Expected result

The server should not crash and user can correct the incorrect syntax.

Actual result

error UNHANDLED REJECTION


  ParseError: KaTeX parse error: Expected 'EOF', got '𝐅' at position 1: �̲�̲ = r_2
  
  - katex.js:2326 new ParseError
    [allaboutspaceflight]/[gatsby-remark-katex]/[katex]/dist/katex.js:2326:16
  
  - katex.js:10416 Parser.expect
    [allaboutspaceflight]/[gatsby-remark-katex]/[katex]/dist/katex.js:10416:23
  
  - katex.js:10468 Parser.parseInput
    [allaboutspaceflight]/[gatsby-remark-katex]/[katex]/dist/katex.js:10468:18
  
  - katex.js:10454 Parser.parse
    [allaboutspaceflight]/[gatsby-remark-katex]/[katex]/dist/katex.js:10454:30
  
  - katex.js:10284 parseTree
    [allaboutspaceflight]/[gatsby-remark-katex]/[katex]/dist/katex.js:10284:17
  
  - katex.js:9223 renderToDomTree
    [allaboutspaceflight]/[gatsby-remark-katex]/[katex]/dist/katex.js:9223:87
  
  - katex.js:9205 Object.renderToString
    [allaboutspaceflight]/[gatsby-remark-katex]/[katex]/dist/katex.js:9205:18
  
  - index.js:12 
    [allaboutspaceflight]/[gatsby-remark-katex]/index.js:12:24
  
  - index.js:31 one

Environment

System:
OS: Linux 4.9 Debian GNU/Linux 9 (stretch) 9 (stretch)
CPU: x64 Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
Shell: 4.4.12 - /bin/bash
Binaries:
Node: 9.0.0 - ~/.nvm/versions/node/v9.0.0/bin/node
Yarn: 1.6.0 - /usr/bin/yarn
npm: 5.5.1 - ~/.nvm/versions/node/v9.0.0/bin/npm
Browsers:
Chrome: 65.0.3325.181
Firefox: 52.9.0
npmPackages:
gatsby: ^1.9.55 => 1.9.273
gatsby-link: ^1.3.2 => 1.6.45
gatsby-plugin-catch-links: ^1.0.8 => 1.0.24
gatsby-plugin-google-analytics: ^1.0.1 => 1.0.31
gatsby-plugin-manifest: ^1.0.7 => 1.0.27
gatsby-plugin-offline: ^1.0.9 => 1.0.18
gatsby-plugin-react-helmet: ^1.0.1 => 1.0.8
gatsby-plugin-sharp: ^1.6.9 => 1.6.48
gatsby-plugin-sitemap: ^1.2.5 => 1.2.25
gatsby-plugin-typography: ^1.7.2 => 1.7.19
gatsby-remark-autolink-headers: ^1.4.7 => 1.4.19
gatsby-remark-copy-linked-files: ^1.5.0 => 1.5.37
gatsby-remark-design-system: ^1.0.9 => 1.0.15
gatsby-remark-images: ^1.5.0 => 1.5.67
gatsby-remark-katex: ^1.0.14 => 1.0.14
gatsby-remark-prismjs: ^1.2.0 => 1.2.24
gatsby-remark-responsive-iframe: ^1.4.1 => 1.4.20
gatsby-remark-smartypants: ^1.4.1 => 1.4.12
gatsby-source-filesystem: ^1.4.1 => 1.5.39
gatsby-transformer-remark: ^1.6.3 => 1.7.44
gatsby-transformer-sharp: ^1.6.10 => 1.6.27
npmGlobalPackages:
gatsby-cli: 1.1.58

File contents (if changed)

gatsby-config.js: N/A
package.json: N/A
gatsby-node.js: N/A
gatsby-browser.js: N/A
gatsby-ssr.js: N/A

[tmfelwu]

There is an option throwOnError that can be passed to katex.render. I tried setting it as false that, but the dev-server still crashes with UNHANDLED REJECTION

[pieh]

I think we need to add handling of this in gatsby-remark-katex - we should catch errors and use reporter.panicOnBuild("some error") - which would terminate gatsby build but only display error in gatsby develop keeping dev server alive.

Would You be interested in creating PR for it?

[tmfelwu]

Sure I'll create a PR for this.

[tmfelwu]

@pieh which function to use to report once in catch, reporter.panicOnBuild?

Won't this exit when the command is not build or am i missing something.

  panicOnBuild(...args) {
    this.error(...args)
    if (process.env.gatsby_executing_command !== `build`) {
      process.exit(1)
    }
  },

[pieh]

You are right - this doesn't seem right. It seems like we aren't actually using it anywhere right now, so that's why this wasn't caught earlier.

[hexrcs]

@sparshy @pieh Is this issue being fixed? 😃 Sort of annoying that the dev server quits whenever I saved before finishing a long formula. 😞

[tmfelwu]

This commit should fix it @hexrcs . Instead of crashing this highlights the error in the formula.

[hexrcs]

@sparshy Thanks man! Made a few changes to your PR #9972 and it should panic on production build now.

[hexrcs]

Fixed in PR #9972. Thanks @sparshy and @pieh!