Question

我正在使用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强制执行的初始中断，以便为附加的节点进程注册断点。

问题但是，我想在调试过程中改进的是，调试器的简单重启还不够重新注册一些新的（或者旧的）断点。我必须完全退出我的应用程序并重新启动它，之前重启后调试器将再次停止在我的构建的第一行并识别我在该阶段添加的断点。

有没有人可以建议改善这种调试体验？与启动调试会话相比，我不介意一些额外的步骤，但是必须手动退出并启动我的应用程序只是为了调试它有点麻烦，并且使得在控制台中实际调试几乎更可取......

感谢您的任何建议！

Answer 1

好的，对于用例，我实际上找到了调试分叉进程的一种非常好的方法。我会把它写出来供将来参考有类似需求的人使用：

我从主进程中分离了子进程的开发。两者都只通过process.on('message', handler)和child.send(...)进行通信。所以基本上我在子进程中进行process.on调用取决于我是否设置process.env.NODE_ENV==='DEBUG'。然后我为子进程做了一个启动配置，比如这个

{
    "type": "node2",
    "request": "launch",
    "name": "Launch child process",
    "program": "${workspaceRoot}/src/main/child_process/Child.ts",
    "cwd": "${workspaceRoot}",
    "outFiles": [
        "${workspaceRoot}/dist/child.js"
    ],
    "env": {
        "NODE_ENV": "DEBUG"
    },
    "sourceMaps": true
}

然后我可以通过使用模拟消息手动调用处理程序来模拟生产环境中通过process.on发出的请求。

调试VS代码中电子产生的子进程

1 个答案: