styleguidist/react-styleguidist

Alternative to process.exit(1) when a webpack module parse error occurs

Open

#1.143 geöffnet am 20. Sept. 2018

Auf GitHub ansehen
 (3 Kommentare) (1 Reaktion) (0 zugewiesene Personen)TypeScript (1.416 Forks)github user discovery
bughelp wanted

Repository-Metriken

Stars
 (11.091 Stars)
PR-Merge-Metriken
 (PR-Metriken ausstehend)

Beschreibung

Configuration:

webpack: 4.19.1
react-styleguidist: 7.0.5
ts-loader: 5.1.1

The problem

When writing React components, it's common to make mistakes using the JSX syntax. For example, you might be mid-development and accidentally save something like:

const Button = (props) => {
  return <button {...props}>{props.children}</button
}

Note the missing > at the end of the JSX declaration.

Even though our webpack configuration is setup correctly, this generates an error from webpack like:

Module parse failed: Unexpected token (145:5)
You may need an appropriate loader to handle this file type.

Styleguidist captures this message in this code and ultimately calls process.exit(1), killing Styleguidist.

This is frustrating because in a medium sized Typescript codebase, restarting Styleguidist can take upwards of 30s.

Commenting the process.exit(1) call out allows the error to be correctly displayed in the browser, and once fixed, allows Webpack to recompile everything correctly.

Proposed solution

The simplest solution would be to only handle these kinds of process.exit(1) errors on startup, and then assume all subsequent module parsing errors are manageable by the user. I can see how this might be a difficult type of Wepback error to make sense of, however, so even I am not convinced this is the best solution.

Alternative solutions

I'm hoping I simply missed something in the docs that allows this class of error to be handled more gracefully. I'm also willing to help with building out a solution, if there is a clear and obvious better path, but I wanted to put out the problem first.

Contributor Guide