[gatsby] How to use VS Code debugger with Gatsby

[Auspicus]

Summary

It's not clear how to debug the build and develop processes now that worker threads are used. VS Code debugger cannot attach to the worker threads properly and yields this error when using the provided launch.json in the documentation:

Provided launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Gatsby develop",
      "type": "pwa-node",
      "request": "launch",
      "program": "${workspaceRoot}/node_modules/.bin/gatsby",
      "args": ["develop"],
      "runtimeArgs": ["--nolazy"],
      "console": "integratedTerminal"
    },
    {
      "name": "Gatsby build",
      "type": "pwa-node",
      "request": "launch",
      "program": "${workspaceRoot}/node_modules/.bin/gatsby",
      "args": ["build"],
      "runtimeArgs": ["--nolazy"],
      "console": "integratedTerminal"
    }
  ]
}

Running gatsby develop on gatsby@4.21.1 with that launch.json on node@14.20.0 yields this error:

 ERROR 

Initiated Worker with invalid execArgv flags: --nolazy



  Error: [ERR_WORKER_INVALID_EXEC_ARGV]: Initiated Worker with invalid execArgv flags: --nolazy
  
  - errors.js:322 new NodeError
    internal/errors.js:322:7
  
  - worker.js:196 new Worker
    internal/worker.js:196:13
  
  - ThreadsWorker.js:51 ThreadsWorker.start
    [debugger-example]/[@parcel]/workers/lib/threads/ThreadsWorker.js:51:19
  
  - Worker.js:104 Worker.fork
    [debugger-example]/[@parcel]/workers/lib/Worker.js:104:23
  
  - WorkerFarm.js:232 WorkerFarm.startChild
    [debugger-example]/[@parcel]/workers/lib/WorkerFarm.js:232:12
  
  - WorkerFarm.js:394 WorkerFarm.startMaxWorkers
    [debugger-example]/[@parcel]/workers/lib/WorkerFarm.js:394:14
  
  - WorkerFarm.js:139 new WorkerFarm
    [debugger-example]/[@parcel]/workers/lib/WorkerFarm.js:139:10
  
  - Parcel.js:567 createWorkerFarm
    [debugger-example]/[@parcel]/core/lib/Parcel.js:567:10
  
  - Parcel.js:232 Parcel._init
    [debugger-example]/[@parcel]/core/lib/Parcel.js:232:20
  
  - Parcel.js:273 Parcel.run
    [debugger-example]/[@parcel]/core/lib/Parcel.js:273:7
  
  - compile-gatsby-files.ts:104 compileGatsbyFiles
    [debugger-example]/[gatsby]/src/utils/parcel/compile-gatsby-files.ts:104:29
  
  - initialize.ts:172 initialize
    [debugger-example]/[gatsby]/src/services/initialize.ts:172:3
  

not finished compile gatsby files - 0.153s

Current docs for running the VS Code debugger on a Gatsby build or develop process: https://www.gatsbyjs.com/docs/debugging-the-build-process/

Steps to Resolve this Issue

1. Determine canonical example for debugging with worker threads
2. Update documentation with new launch.json config, add any other required config or information

[Auspicus]

Using PARCEL_WORKERS=0 disables the worker threads so that the --no-lazy argument can be passed. GATSBY_CPU_COUNT=1 requests that Gatsby does not parallelize beyond one thread. This allows the debugger to run but I'm still having a hard time getting breakpoints set in .tsx files or gatsby-node.ts to be picked up. Switching to gatsby-node.js works fine.

[Auspicus]

Seems like this line here explicitly disables source maps for compilation of Gatsby files. To my understanding this would be done to prevent security concerns, however I'm going to try enabling it to see if I can get the debugger to find the source files.

gatsby/packages/gatsby/src/utils/parcel/compile-gatsby-files.ts

Line 44 in 9d737b6

sourceMap: false,

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 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.
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! 💪💜

[Auspicus]

Bump. See: #36450