我所知道的JS调试
前言
任何一门语言都有对应的调试方法,也有对应的调试工具,JavaScript当然也不例外。最常用的莫过于浏览器这个调试工具了。而今天我们要讲的对于这个基础调试就不细说,我会将目前所有调试javascript(nodejs)的方法以及工具(主要是VS Code)介绍一下,然后顺便讲解一下webpack的sourcemap功能。
1 前置条件
- Chrome: 55+
- Nodejs: 6.3+
我当前使用的Nodejs(7.10)和Chome(Version 59.0.3071.104)
该文章配合了一个demo: javascript-debug-demo
2 如何利用sourceMap来调试或者定位我们的错误
现代的网页越来越复杂,加上有babel这类的工具来对我们写的Js代码转译,然后有uglify这类工具进行压缩,最后我们看到的代码与原先的代码相差将会很大,单纯靠打印调试是效率极低的,于是这个时候sourceMap这个功能便应运而生。
在这里我们结合最火爆的打包工具webpack来说说如果利用webpack的sourcemap功能来调试以及定位错误的位置。
首先使用chrome调试带有sourcemap功能的js文件需要有下面的条件:
- chrome开启支持
sourcemap
的功能 - webpack配置
devtool
参数
开启chrome的sourcemap支持:
如果配置webpack但是没有开启支持,那么chrome的控制台将会是这样的:
如果开启支持但是没有对应的sourcemap文件:
满足以上两个条件就可以:
在webpack的官网文档中提供了10中方法,那么这10种方法有哪些区别,我们要如何更好地利用这些参数去调试呢?下面我们一一通过图片来简单地过一遍。
2.1 eval
该方法官方文档标榜是效率最高的,它会使用eval
执行每一个module,然后每个module后面都会跟着//@ sourceURL
。如下图:
配置如图:
生成的文件如下图:
官网文档说该方法的最大缺点是不能准确地显示行号,但下面的报错图是我截取的,貌似行号是正确的显示的。不建议用于产品环境下。
2.2 eval-source-map
这个就是把eval
的sourceURL
换成了完整souremap信息的DataUrl
,刚开始第一次编译的时候是比较慢,但重新编译的时候速度会大大地变快。其对应的行号可以正确显示因为其是从原始代码来做映射的。对应的配置和报错图如下:
报错提示:
不建议用于产品环境下。
2.3 inline-source-map
为每一个文件添加sourcemap
的DataUrl
,注意这里的文件是打包前的每一个文件而不是最后打包出来的,同时这个DataUrl
是包含一个文件完整souremap
信息的`Base64 格式化后的字符串,而不是一个url。对应的配置文件:
错误的定位情况以及生成的文件如下:
不建议用于产品环境下。
2.4 cheap-eval-source-map
类似于eval-source-map
,但是取名为cheap
是因为它没有列映射,只有行映射。对应的webpack配置如图:
其生成的文件如下:
报错的定位情况:
不建议用于产品环境下。
2.5 cheap-module-eval-source-map
类似于cheap-eval-source-map
,但是官网称这个选项可以更好地处理映射。对应的配置如下:
错误的定位情况如下:
不建议用于产品环境下。
2.6 source-map
该选项会生成一个sourcemap文件,然后在bundle文件中添加一个引用声明,这样开发工具可以知道在哪里找到sourcemap文件,对应的配置如下:
生成的sourcemap文件大致如下:
错误定位情况如下:
2.7 hidden-source-map
和source-map
一样,但是不会添加引用声明到bundle文件中。如果你只想要让sourcemap从错误报告中映射错误堆栈追溯,但是不想暴露你的sourcemap文件给开发者工具的话,这种方式很适合你的。对应的配置如下:
错误定位情况:
2.8 cheap-source-map
类似于source-map
,但是没有列映射。对应的配置如下:
错误定位情况:
bundle文件最后的注释如下:
2.9 cheap-module-source-map
此种方法也没有列映射,同时 loader 的 sourcemap 也被简化为只包含对应行的。最终的sourcemap
只有一份,它是webpack
对 loader生成的sourcemap
进行简化,然后再次生成的。对应的配置如下:
错误定位情况:
2.10 nosources-source-map
该方法生成的sourcemap文件没有sourcesContent
字段,如下:
配置如下:
错误定位情况:
3 前端代码debugger调试
如果我们在前端代码中指定的位置打断点,除了可以直接在控制台中直接打断点,还可以在你的代码中添加debugger
关键词来打断点:
4 Nodejs的调试
Nodejs写多了,就免不了调试,而最低级的console打印貌似满足不了调试nodejs,于是我们就开始寻求新的调试方法,今天就给大家列举两种常用的调试工具。
首先我们需要开启Nodejs调试状态,只需要在启动的文件使用--inspect
即可,如下图:
于是在终端会打印出下面的红框中的重要的一行话:
1Debugger listening on port 5859. 2[1] Warning: This is an experimental feature and could change at any time. 3[1] To start debugging, open the following URL in Chrome: 4[1] chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:5859/39515fe7-3f4a-40b2-8b95-6196a2d22d73
眼尖的童鞋肯定会发现为什么你的打印中出现了两次Debugger listening on port
,那是因为我使用的Nodejs文件监控重启包是piping
,而这个包的一个最大的特点便是:
使用默认的设置的时候,那么将会启动第二个实例,这个实例由第一个实例监控。Piping在第一个实例中故意人为的引发uncaughtException操作来避免继续执行其他代码,所以真正执行服务器代码的是在第二个实例,这也就是我们应该使用第二个打印的原因。
4.1 Chrome调试Nodejs
基于上面的介绍,我们将第二个实例打印的调试地址粘贴复制到Chome地址栏中,即可打开调试窗口,然后在你想要打断点的地方加上断点即可:
4.2 VSCODE调试Nodejs
除了使用chome,你还可以使用VSCode这个神器。使用VScode调试得配置一下:
使用如下的调试配置:
1{ 2 // Use IntelliSense to learn about possible Node.js debug attributes. 3 // Hover to view descriptions of existing attributes. 4 // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 5 "version": "0.2.0", 6 "configurations": [ 7 { 8 "name": "Attach to Process", 9 "type": "node", 10 "protocol": "inspector", 11 "request": "attach", 12 "address": "localhost", 13 "port": 5859 14 } 15 ] 16}
其中端口的配置记得和之前打印的调试端口一致,这里都是5859。
然后启动你的Nodejs服务,接着按下F5
,就可以进入调试状态,打上断点,同样可以查看本地变量/堆栈等等信息。如下图:
参考
公众号关注一波~
![微信公众号](https://blogimage.5udou.cn/homePage/%E5%85%AC%E4%BC%97%E5%8F%B7-%E7%99%BD%E8%89%B2%E7%89%88.png?x-oss-process=style/addWaterMarkBottom)
网站源码:linxiaowu66 · 豆米的博客
Follow:linxiaowu66 · Github
关于评论和留言
如果对本文 我所知道的JS调试 的内容有疑问,请在下面的评论系统中留言,谢谢。