[enlyth]

> JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode

I don't get it, is this some Gatsby limitation? I've been debugging JSX since the dawn of time with breakpoints, even with SSR and typescript

[c0ffe]

To me its a bit tricky to summarize, so its a long answer.

During the build, Gatsby compiles JSX and saves the result in a temporal folder. Some time after, it spawns several subprocesses that execute the mentioned resulting JS files (to render each page in the site).

What I meant with "the JSX code is hard to debug" is:

* The JSX code is actually run inside subprocesses, and NodeJS allows to debug a process if its run with the `--inspect` command line argument. But I did not found documentation in the Gatsby website about how to change the arguments of these subprocesses. Note that this only applies to production builds (development mode executes all JSX in the browser).

* From the text editor perspective, the breakpoints are defined in the original JSX source files, not the built ones. I understand that in theory line/column mapping can be done using map files, but I did not have time yet to investigate the cleanest way to make the IDE, Docker (not actually a Gatsby requirement), the temporal Webpack build directory, and Gatsby subprocesses to work together.

[kilburn]

Gatsby does ssr in batch during build time. The pages are rendered in a pool of worker processes. I haven't found a way to tell gatsby to attach my debugger when launching those processes.

Gatsby's docs on debugging HTML builds [1] give you adhoc solutions for specific problems you may have, but 0 info on actually debugging.