"Debug: Attach to Node Process" + sourceMapPathOverrides

[borekb]

Debug: Attach to Node Process is an awesome feature – no need to update npm scripts with --inspect and, most of the time, no need to create launch.json configs.

However, I'm in a situation where I'm trying to debug a Node.js project in a subfolder in my workspace. So in a console, I do:

cd subfolder
yarn dev

VSCode can successfully attach to the process but all paths are broken – the debugger sends paths like src/server.ts but VSCode should interpret this as subfolder/src/server.ts.

If I started the process via launch.json (which I generally don't like too much – it duplicates a few things from package.json, not all team members are using VSCode, etc.), this would work:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Example",
      "runtimeExecutable": "node",
      "runtimeArgs": ["--inspect", "node_modules/.bin/next", "dev"],
      "port": 9229,
      "cwd": "${workspaceFolder}/subfolder",
      "sourceMapPathOverrides": {
        "webpack:///./*": "${workspaceRoot}/subfolder/*",
      }
    }
  ]
}

I just learned today about sourceMapPathOverrides and it makes VSCode work, however, I'd really much prefer to be able to do Debug: Attach to Node Process and still somehow tell VSCode to apply a custom mapping.

[connor4312]

In tomorrow's nightly of our new debugger (when installed, it will register a command Debug: Attach to Node Process (preview)) you'll be able to add defaults in your user or workspace settings, like so:

"debug.javascript.pickAndAttachOptions": {
  "sourceMapPathOverrides": {
    "webpack:///./*": "${workspaceRoot}/subfolder/*",
  }
}

Let us know if you run into any more issues!

(Versifiers: easiest way to test is add this option with trace: true and verify that the debug adapter prints "Verbose logs are written to: ..." in the debug console)

[borekb]

Oh wow, I thought I'm in some edge case and a few hours later, this issue is fixed 😄.

Workspace setting sounds great, and what you suggest in vercel/next.js#10807 (comment), i.e., being able to detect path mappings automatically with the help of lsof, sounds even better. Is there already an open issue for it?

[borekb]

@connor4312 Actually one point to the solution mentioned above:

Our monorepo has several Next.js projects in subfolders, like this:

- <workspace root>
    - nextjs-app-1
    - nextjs-app-2
    - nextjs-app-3

So having a single path mapping probably will help only partially – in some README, I'll probably need to suggest that the person debugging should update .vscode/settings.json temporarily (making the file modified as far as Git is concerned, which is a bit annoying).

Again, if lsof could solve that, that would be great. Otherwise, I'm not sure that there's much to do about that, maybe some sort of "interactive Attach to Node Process" that would ask for a real folder path via quick pick UI?

[connor4312]

We already use lsof when it's available 🙂 But right now it's only used when there's 0 or >= 2 workspace folders open--if there's exactly one open folder, we use that as the process cwd. As of microsoft/vscode-js-debug#326, for normal launches we set the cwd based on the nearest package.json-containing folder. Maybe we can adjust our attachment algorithm to do the same--if lsof is available, use the nearest package.json-containing folder inside any workspace folder. For Node.js, sourcemap resolution happens relative to the working directory, so that should work here, I think.

microsoft/vscode-js-debug#413, should get to it early next week

[borekb]

For normal launches we set the cwd based on the nearest package.json-containing folder. Maybe we can adjust our attachment algorithm to do the same.

That sounds great indeed.

If I understand correctly, the attach would detect nextjs-app-1/package.json, set cwd to nextjs-app-1 and all paths (which are currently relative to nextjs-app-1, not our workspace root) would suddenly work.

[connor4312]

Yep, that's right.

[connor4312]

To verify:

1. Add the setting "debug.javascript.pickAndAttachOptions": { "trace": true }
2. Run node --inspect in some terminal
3. Run the command Attach to Node.js Process (preview) and pick that process
4. Verify that the location debug log file is printed to the debug console (i.e. that the trace setting applied to attachment)

[JacksonKearl]

Followed the steps but not seeing the log?

[connor4312]

@JacksonKearl the log should be in the "debug console" view, rather than the terminal.

[JacksonKearl]

I'm seeing the attach create two debug consoles, Node.js Process and process, and the log is shown in process. Node.js Process is empty. Is this expected?

[connor4312]

I think that's intended behavior (cc @isidorn) so that you don't lose previous logs if you run a new launch config. (I see the same thing, but with an "Extension Host" entry since that happens to be the last thing I debugged).

[isidorn]

Yes this is designed behavior.