Enable --inspect & --inspect-brk arguments on the build/develop args

Summary

Add gatsby --inspect & and gatsby --inspect-brk commands to gatsby to enable easier debugging.

Now with node 10 we can use the https://nodejs.org/docs/latest-v10.x/api/inspector.html API to enable debugging programmatically, especially with the new gatsby develop changes.

For develop we could just enable it when we spawn the command.

Basic example

When gatsby --inspect is ran, in gatsby we do:

const inspector = require('inspector');

inspector.open()

Motivation

Fixes https://github.com/gatsbyjs/gatsby/issues/24349#issuecomment-635384602

[pieh]

I think that in gatsby develop “child process” is process that people most likely would want to debug (as this is the process where most of code is being executed, including all the plugins and user code) and optimizing for ease of setting up debugger for that process should be goal here (IMO).

So what about something in the middle between option 1) and 2):

• --inspect-brk could set up child process (develop-process) using regular nodejs semantics (port 9229 unless specified otherwise via cli option)
• --multi-process-inspect-brk - boolean switch which will open debug ports on all other process (parent process, jest-worker ones, etc) - this would be using random ports out of necessity. Separating this from “happy path” also have some nice characteristics - depending on your setup ( a) everyone use vscode b) for profiling you need chrome-dev-tools/ndb) - connecting to multiple processes waiting for debugger might be a pain, so having happy path to only handle one of them seems like good idea in my head

(it doesn’t have to be single change to address all of those - I think addressing happy path first with plan on how to address more complex one is very reasonable)

What do you think?

[herecydev]

So the good news is I got it to debug the child process 🚀

However, there’s actually a non-trivial amount of choice/complexity here. I’ll try and articulate this as best as possible:

Parent process = develop.ts running before spawn is called Child process = develop-process.ts, runs as a result of the spawn call and handles the majority of what gatsby does

Option 1

Tell the child process to use the inspector on the default port (9229) or a chosen port if the user supplies one: --inspect-brk=10876. The upside of this is that vscode sees --inspect-brk and with auto-attach on will correctly attach to the child process and you can debug the majority of gatsby including user code. This would allow a simple gatsby dev --inspect-brk to work for most scenarios from the cmd line.

Downside: You’re unable to debug the parent code, although it’s minimal. Uses default port so only 1 debug at a time, unless you’re supplying a chosen port

Option 2

Tell the child process to use the inspector on a random port. By passing a “fake --inspect-brk” argument to the spawn command, vscode will attach to this automatically if autoAttachChildProcesses is true.

Advantage: Debug all the things! 🎉 + uses random ports to avoid collision. vscode end to end debugging is easy Disadvantage: Because the port is random it might not be intuiative for some tools to debug (i.e. it’s not the default 9229)

I feel like option 2 is better, but I’m also skewed on my opinion because almost everyone I know uses vscode. Another very important note is how the vscode javascript debugger preview negates any need for this; simply spawning another process will automatically attach.

@wardpeet let me know your thoughts!