【问题标题】:Breakpoints do not stay on their line in debugger both in Chrome and VS Code在 Chrome 和 VS Code 中,断点不会留在调试器中
【发布时间】:2020-06-05 12:37:55
【问题描述】:

我一直想弄清楚为什么我的调试器没有将断点放在相应的行上。

如下图所示,断点没有按预期工作:

Misbehaving breakpoints in Chrome


对于 VS 代码,这是我正在运行的脚本:

"test-script": "env-cmd -f ./config/dev.env nodemon --inspect-brk --exec 'babel-node ./tests/$TEST_SCRIPT'"

Disappearing breakpoints in VS Code


我不确定这是 babel/webpack 错误配置还是调试器中设置的错误。

  • .babelrc 我尝试将sourceMaps 设置为true, "both", 和"inline" 但这并不能解决问题。
  • 在我的 webpack 配置中,我 有devtool = source-mapmode = development

我真的不希望将console.log 语句放在任何地方,而是按预期使用调试器,因此我们将不胜感激。

谢谢!

【问题讨论】:

  • 我不知道是不是一样的东西,但是在其他语言中,当断点不在它的实际位置时,意味着编译后添加或删除了一些代码。这敲响了警钟吗?

标签: javascript debugging visual-studio-code google-chrome-devtools babeljs


【解决方案1】:

当您为没有它们的目标环境转换 async 函数时,看起来会发生这种情况。它们最终被彻底改造,以至于 regeneratorRuntime 可以处理它们,甚至源映射也无济于事。我通过在直接支持它们的现代浏览器上设置项目而不是在开发和调试期间转换 async 函数来解决它。然后我们使用生产(转译)构建在目标 pre-async 浏览器上进行测试。如果我们必须追查仅在编译时发生的问题(非常罕见),我们将其重新打开以供开发人员使用并插入 debugger; 语句。 :-|

【讨论】:

  • 谢谢 TJ,我以为我要疯了才能弄清楚这一点。此处提供的问题的链接的答案之一提到了此 使用默认环境设置。如果您将 env 字符串更改为 chrome>60(或者实际上,有趣的是 >4%!),代码将按原样传递,因为 Chrome > 60 原生支持 async/await 和箭头函数。 在两个调试器中都为我修复了它。 stackoverflow.com/questions/52704820/…
  • 有什么方法可以解决这个问题,而无需在开发期间禁用异步函数的转译?我的意思是确定这是一个好方法,但这可能会导致错误溜走而被忽视。也许更新版本的 babel 在源映射任务上会做得更好?
  • @sktguha - async 函数代码到生成的再生器运行时状态机代码的有效源映射似乎是一个非常难题。我从来没有见过它做得很好。但我也从未(实际上从未)见过使用再生器运行时的生产转译代码存在直接运行等效的async 函数代码没有的问题。
  • “但我也从未(实际上从未)见过使用再生器运行时的生产转译代码存在直接运行的等效异步函数代码没有的问题。”我懂了。如果没有发生错误,那么是的,对于更好的 DX,答案是好的,是的。
  • @sktguha - 不能说它从未发生在其他人身上。 :-) 对我来说不是。
猜你喜欢
  • 2019-11-09
  • 1970-01-01
  • 2019-02-10
  • 1970-01-01
  • 1970-01-01
  • 2018-10-16
  • 2019-03-19
  • 2019-05-14
  • 2020-10-18
相关资源
最近更新 更多