Alternative to process.exit(1) when a webpack module parse error occurs
#1,143 opened on Sep 20, 2018
Repository metrics
- Stars
- (11,091 stars)
- PR merge metrics
- (PR metrics pending)
Description
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.