javascript 如何强制 Chrome 调试工具以漂亮的代码进行调试？

How to force Chrome debugging tools to debug in pretty code?

提问by Ante

Although I used pretty code and had set up the breakpoints in "Pretty code" tab, debugger keeps working in minified code. (I can't see exactly where I am and need to continuously switch between source and "pretty code"). On same pages with same script it sometimes work and sometimes don't. I can't find the cause or any difference in the way I activate it.

尽管我使用了漂亮的代码并在“漂亮的代码”选项卡中设置了断点，但调试器继续在缩小的代码中工作。（我无法确切地看到我在哪里，需要在源代码和“漂亮代码”之间不断切换）。在具有相同脚本的相同页面上，它有时会起作用，有时则不会。我找不到原因或激活它的方式有什么不同。

Is there any way to force debugger to use "pretty code"? Any Ideas or additional questions? Should this be reported as a bug?

有没有办法强制调试器使用“漂亮的代码”？任何想法或其他问题？这应该报告为错误吗？

EDIT: I still don't understand what is going on but there is a fix for it. So when this situation happens, just edit script and add "debugger;" keyword after the cursor. It will make a breakpoint. Then, if you use "pretty code", debugger will stay inside prettified code. As I said, I don't understand why is this happening so I'm still waiting for answer(s).

编辑：我仍然不明白发生了什么，但有一个修复方法。所以当这种情况发生时，只需编辑脚本并添加“调试器”；光标后的关键字。它将创建一个断点。然后，如果您使用“漂亮的代码”，调试器将留在美化的代码中。正如我所说，我不明白为什么会发生这种情况，所以我仍在等待答案。

EDIT: Current browser version is 42.0.2311.135 (64-bit).

编辑：当前浏览器版本为 42.0.2311.135（64 位）。

EDIT: Dave pointed out that there is a reported bug on something very similar. https://code.google.com/p/chromium/issues/detail?id=415406It says it's related to file size but I can't confirm this. I changed title to reflect these findings.

编辑：戴夫指出，有一个非常相似的错误报告。https://code.google.com/p/chromium/issues/detail?id=415406它说这与文件大小有关，但我无法确认。我更改了标题以反映这些发现。

回答by Dave Alperovich

You can call this a bug. You can call it a dillema.

您可以将其称为错误。你可以称之为困境。

Open ticket from Aug 9, 2013(Chrome v. 28)

2013 年 8 月 9 日起的公开票（Chrome v. 28）

Bug Reporter's observations

错误报告者的观察

I've been spending some time debugging this, and familiarizing myself with how to develop devtools locally; I'm not sure if all of this is helpful, but here's a braindump of what I've looked at so far and some hunches:

When attaching a breakpoint in the original .js file, the UI seems to get confused and assigns the breakpoint to the associated .coffee or .ts file per the sourceMap association [see image-1, attached]

However, when unchecking the breakpoint to disable, the UI correctly updates to show the breakpoint in the right place in the .js file. [see image-2, attached]

It seems to me there is either an incorrect lookup happening in WebInspector.CompilerScriptMapping.rawLocationToUILocation or WebInspector.CompilerScriptMapping.uiLocationToRawLocation

我花了一些时间调试它，并熟悉如何在本地开发 devtools；我不确定所有这些是否有帮助，但这是我迄今为止所看到的内容和一些预感的脑残：

在原始 .js 文件中附加断点时，UI 似乎会感到困惑，并根据 sourceMap 关联将断点分配给关联的 .coffee 或 .ts 文件 [参见图片 1，附件]

但是，当取消选中要禁用的断点时，UI 会正确更新以在 .js 文件中的正确位置显示断点。[见图片 2，附上]

在我看来，WebInspector.CompilerScriptMapping.rawLocationToUILocation 或 WebInspector.CompilerScriptMapping.uiLocationToRawLocation 中发生了不正确的查找

Open ticket from Sep 21, 2014(Chrome v. 37)

2014 年 9 月 21 日起的公开票（Chrome v. 37）

Chromium Developer's Observation

Chromium 开发者的观察

This is not something that could be solved easily. The breakpoint manager is build around the idea that the breakpoint is always shown in the "best possible" UI location, which is uncompiled source in case of source maps. Fixing this would require us to use breakpoint's primary ui location as a hint to where it should be shown. Moreover since execution line will be shown in the uncompiled sources by default, it is essential that we keep showing our breakpoints in them as well. So this all ends up in the need to show breakpoints (and execution line) on several ui locations at the same time. All actions with these locations should work smoothly etc.

This is a significant effort and does not sound like a "GoodFirstBug" to me.

这不是可以轻易解决的事情。断点管理器是围绕断点始终显示在“最佳” UI 位置的想法构建的，在源映射的情况下，该位置是未编译的源。解决这个问题需要我们使用断点的主要 ui 位置作为它应该显示的位置的提示。此外，由于默认情况下执行行将显示在未编译的源代码中，因此我们也必须继续在其中显示断点。所以这一切最终都需要在多个 ui 位置同时显示断点（和执行行）。这些位置的所有操作都应该顺利进行等。

这是一项重大的努力，对我来说听起来不像是“GoodFirstBug”。

---

---

Conclusion:

结论：

Prettify does not seem to create a new non-minified version. Rather it is rendered. This makes sense. With all the different frameworks and flavors (e.g. Coffee), if the debugger created a new file, there is high potential for error.

Prettify 似乎没有创建新的非缩小版本。而是渲染。这是有道理的。对于所有不同的框架和风格（例如 Coffee），如果调试器创建了一个新文件，很可能会出错。

The breakpoint manager is build around the idea that the breakpoint is always shown in the "best possible" UI location, which is uncompiled source in case of source maps.

断点管理器是围绕断点始终显示在“最佳” UI 位置的想法构建的，在源映射的情况下，该位置是未编译的源。

I interpret this to mean the Chrome browser and debugger will continue running from the minified version. When you set a break-point in a "pretty" file, the debugger sets it in the minified file and gives the developer a "pretty" rendering of debugger stepping through minified file.

我认为这意味着 Chrome 浏览器和调试器将继续从缩小版本开始运行。当您在“漂亮”文件中设置断点时，调试器会将其设置在缩小文件中，并为开发人员提供调试器逐步执行缩小文件的“漂亮”渲染。

This is a lot for the debugger to manage, and can be rather fragile. We can call this a bug or a very ambitious feature for which many things can go wrong.

这对于调试器来说需要管理很多，并且可能相当脆弱。我们可以将其称为错误或非常雄心勃勃的功能，许多事情都可能出错。

**

**

I have added this thread to both bugs and emailed both developers assigned to it.

我已将此线程添加到两个错误中，并通过电子邮件发送给分配给它的两个开发人员。

**

**

回答by peterpeterson

In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.

在 Chrome 和 Safari 中，只需选择“脚本”选项卡，找到相关文件，然后按位于底部面板中的“{}”（漂亮的打印）图标。

回答by Pakosis

How about this?: Generate the pretty-print version of your "min" version and save using your "min" version name: Substitute the "min" for a pretty "one"

怎么样？：生成“min”版本的漂亮印刷版本并使用“min”版本名称保存：用“min”替换漂亮的“one”

回答by Chris Gunawardena

Seems like you are clicking the "{ }" (pretty print) icon located in the bottom panel and setting a breakpoints there without attaching a source mapof the original file.

似乎您正在单击位于底部面板中的“{}”（漂亮的打印）图标并在那里设置断点而不附加原始文件的源映射。

When given a .map file, Chrome dev tools and map each line of executed minified code to the original source file using the data in the .map file. Otherwise it will just do it's best to indent/format the minified file.

当给定一个 .map 文件时，Chrome 开发人员会使用 .map 文件中的数据将每一行已执行的缩小代码映射到原始源文件。否则它只会缩进/格式化缩小的文件。

I suggest you use grunt uglify or similar to minify your js which will automatically generate a map file for debugging. See the following links for more information on how to do this.

我建议你使用 grunt uglify 或类似的工具来缩小你的 js，它会自动生成一个用于调试的地图文件。有关如何执行此操作的更多信息，请参阅以下链接。

http://blog.teamtreehouse.com/introduction-source-maps

http://blog.teamtreehouse.com/introduction-source-maps

Javascript .map files - javascript source maps

Javascript .map 文件 - javascript 源映射

回答by Andrew Olney

As of 2020, similar behavior still occurs in a specific situation:

到 2020 年，在特定情况下仍会出现类似行为：

• You open a source-mapped document, i.e. it shows "(source mapped from ...)" on the bottom of the window
• You prettify it
• You place a breakpoint in the prettified version
• The debugger will stop in the ugly source-mapped file

• 您打开一个源映射文档，即它在窗口底部显示“（源映射自...）”
• 你美化它
• 您在美化版本中放置一个断点
• 调试器将在丑陋的源映射文件中停止

The solution seems to be to go to the original source from which you mapped, prettify that, and place the breakpoint there.

解决方案似乎是转到您映射的原始源，美化它，然后在那里放置断点。

Chrome 79.0.3945.88 ; Webpack 4.41.2

铬 79.0.3945.88 ；网络包 4.41.2