在VS代码中调试由电子产生的子进程(Debugging child process spawned by electron in VS code)

 我正在使用webpack在typescript中构建一个电子应用程序，我遇到了以下vscode调试问题： 
 
 信息：主进程通过调用fork('./dist/child', [], {execArgv: ['--debug-brk=3001']})生成子进程。 我的launch.json如下所示： 
 
{
    "name": "Debug child process",
    "type": "node",
    "request": "attach",
    "address": "localhost",
    "port": 3001
}
 
 脚步： 
 
 
 
 我在终端启动了我的电子应用程序 
 
 
 点击F5启动vscode调试器 
 
 
 正如预期的那样，它在我的webpack构建的第一行中为子进程代码打破了一次（由于debug-brk ）。 这允许我在我的打字稿源中使用调试器注册其他断点。 
 
 
 
 正如预期的那样，一旦继续，vscode会在我的ts源中很好地击中那些断点。 好。 
 
 
 问题：如果我现在重新启动调试器（没有任何源更改或注册新断点）... 
 
 
 
 构建中的初始断点未被命中 
 
 
 我手动添加的断点被标记为忽​​略（ 断点被忽略，因为找不到生成的代码（源映射问题？）。 ） 
 
 
 此时我添加的任何新断点也会被标记为忽​​略。 
 
 
 我意识到Attach的调试与Launch的调试不同，并且需要一个debug-brk fork强制执行的初始中断，以便为连接的节点进程注册断点。 
 
 问：但是，我想在调试过程中改进的是，调试器的简单重启不足以重新注册一些新的（或旧的）断点。 我必须完全退出我的应用程序并再次启动它， 然后在重新启动时调试器将再次停止在我的构建的第一行并识别我在该阶段添加的断点。 
 
 有没有人可以建议改善这种调试体验？ 与启动调试会话相比，我不介意一些额外的步骤，但是必须手动退出并启动我的应用程序只是为了调试它有点麻烦，并且实际上在控制台中实际调试几乎更可取... 
 
 谢谢你的建议！ 

I am building an electron app in typescript with webpack, and I am running into the following vscode debugging problem:
 
Info: The main process spawns a child process by calling fork('./dist/child', [], {execArgv: ['--debug-brk=3001']}). My launch.json looks as follows:
 
{
    "name": "Debug child process",
    "type": "node",
    "request": "attach",
    "address": "localhost",
    "port": 3001
}
 
Steps: 
 
 
 
I launch my electron app in a terminal
 
 
hit F5 to launch the vscode debugger
 
 
As expected, it hits a break at the first line of my webpack build for the child process code (due to debug-brk). This allows me to register additional breakpoints with the debugger in my typescript source.
 
 
 
as expected, upon continuing, vscode hits those breakpoints nicely within my ts source. Good.
 
 
Problem: If I now restart the debugger (without any source changes or registering new breakpoints)...
 
 
 
The initial breakpoint in the build is not hit
 
 
My manually added breakpoints are marked ignored (Breakpoint ignored because generated code not found (source map problem?).)
 
 
Any new breakpoint I add at this point is also marked ignored. 
 
 
I realize that debugging by Attach is different from debugging by Launch, and that the initial break enforced by a debug-brk fork is needed to give one the opportunity to register breakpoints for a node process that is attached to. 
 
Question: However, what I would like to improve in my debugging experience is that a simple restart of the debugger is not enough to re-register some new (or old) breakpoints. I have to entirely exit my app and start it again, before the debugger upon restart will again halt at the first line of my build and recognize breakpoints I add at that stage. 
 
Is there a way anybody could recommend to improve this debug experience? I don't mind some extra steps as compared to a Launch debugging session, but having to manually quit and start my app just to debug it is a bit cumbersome, and makes actually debugging in the console almost more preferable... 
 
Thanks for any advise!

原文：https://stackoverflow.com/questions/42495365