Chrome Dev工具,不寻常的行为,显示变量不确定,但仍可以访问成员

发布于 2025-01-31 03:31:56 字数 740 浏览 4 评论 0 原文

我可能需要一些帮助,以更好地解释和定义此问题,我只知道这在Chrome DevTools中发生,我要查看的代码已与包裹编辑,并且我在4.4之后使用了某种版本的Typescript 。

在这里500之后,我已经踏上了几行, const解析在悬停和范围窗口中显示不确定。如果确实不确定,则 parsed.type 应该抛出,以及我处于-506的行,它可以访问 .value

但是,经过几步之后,我在507(!)上降落 。

{type:'ok',value:'custom-plot'} img src =“ https://i.sstatic.net/cv8ia.png” alt =“在此处输入图像说明”>

我对包裹的经验非常有限,但是我很肯定我能够能够为了获得更好的体验,请在钉上适当的webpack时进行调试,我什至

最少 会开始调试在那部作业之后。

编辑

我已经升级了包裹,并让它表现得更好,但我仍然很好奇工具链的哪一部分导致了这一点。

I might need some help with better explaining and defining this problem, as is i only know this happens in chrome devtools, that the code i'm looking at has been compiled with parcel, and that i'm using some version of typescript after 4.4.

I've stepped a few lines after 500 here, and const parsed shows as undefined both when i hover and in the scope window. If it were indeed undefined, parsed.type should have thrown, as well as the line i'm at - 506 where it accesses .value

enter image description here

However, after a few more steps, i land on 507 (!) and now i can see that there is indeed something in parsed and that there must have been before stepping (the scope window shows parsed as {type: 'ok', value: 'custom-plot'}.

enter image description here

I have very limited experience with parcel, but i'm positive that i've been able to get a better experience debugging typescript when nailing a proper setup for webpack. Where and how could i even start debugging this?

At a minimum, i'd like to tell the debugger to move past 500, and really truly see whats in that variable after that assignment.

EDIT

I've upgraded parcel and got this to behave better out of the box, still im curious which part of the tool chain was causing this.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

我最亲爱的 2025-02-07 03:31:56

它可能是包裹,或者由包裹内部使用的工具(SWC/Babel/TSC,具体取决于您的设置)。 (尽管这是一个猜测 - 很难确定,没有我可以调试的完整复制)。包裹负责生成源地图,源地图中的错误很容易导致您看到的问题 - 在 .ts 代码之间存在不匹配的地方,Debuggers表示它已停止,停止,至于变量,控制流等方面,实际上实际上正在发生的事情。

升级包裹的事实导致该问题消失了,这支持了这一理论。您还可以在。如果您将来继续遇到此类问题,我建议尝试创建简化的复制品并用包裹提交错误。

It probably was parcel, or the tools used internally by parcel (swc/babel/tsc, depending on your setup). (Although this a guess - hard to know for sure without a full repro that I could debug). Parcel is responsible for generating the source maps, and bugs in source maps can easily cause the kinds of issues you saw - where there's a mismatch between the line of .ts code that the debuggers says it's stopped on, and what really appears to be happening as far as variables, control flow, etc.

The fact that upgrading parcel caused the problem to go away supports this theory. You can also see a number of source-map related bugs being fixed in the parcel changelog. If you continue to experience issues like this in the future, I'd suggest trying to create a simplified reproduction and filing a bug with parcel.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文