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

[wardpeet]

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

[herecydev]

I fancy giving this a try, would be good to better understand the recent socket changes

[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!

[herecydev]

@wardpeet I've added an implementation for just the --inspect-brk. I can add an --inspect if you're happy with that and rewrite some of the docs here: https://www.gatsbyjs.org/docs/debugging-the-build-process/

[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]

Okay we can take the first option and tackle the multi process separately. For reference this is how the new vscode debugger (preview) would be setup:

 "version": "0.2.0",
  "configurations": [
    {
      "name": "Gatsby develop",
      "type": "node",
      "request": "launch",
      "protocol": "inspector",
      "program": "${workspaceRoot}/node_modules/gatsby/dist/bin/gatsby",
      "args": ["develop"],
      "stopOnEntry": false,
      "runtimeArgs": ["--nolazy"],
      "sourceMaps": true,
      "skipFiles": ["<node_internals>/**"],
    }
  ]

Having tried that, it "just works" with no code changes required. Breakpoints are hit on the first line, maps to typescript works, and child processes are attached automatically. It will also listen on a random port automatically. So I think it would be good to supply some advice for users who are using this (I think it ships with the insiders builds now)

I don't want to just support vscode but it's also difficult to know all the use cases as well

[wardpeet]

Unsure how vscode preview debugger works but this was my idea.
When people run --inspect-brk & --inspect with node <path to gatsby> they will stop as node would. If they use gatsby --inspect we would attach it to the develop-process.

We can do the multi proc thing as a follow up but this sounds reasonable to me, what do y'all think?

[herecydev]

@wardpeet and @pieh I think I've captured the behavior you were after. Still needs some docs adding but let me know your feedback.

[github-actions[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[JacoboGallardo]

any news? The workaround suggested in #24349 did not work for me.

Thanks.