我所知道的JS调试

前言

任何一门语言都有对应的调试方法，也有对应的调试工具，JavaScript固然也不例外。最经常使用的莫过于浏览器这个调试工具了。而今天咱们要讲的对于这个基础调试就不细说，我会将目前全部调试javascript(nodejs)的方法以及工具(主要是VS Code)介绍一下，而后顺便讲解一下webpack的sourcemap功能。

1 前置条件

1. Chrome: 55+
2. Nodejs: 6.3+

我当前使用的Nodejs(7.10)和Chome(Version 59.0.3071.104)

该文章配合了一个demo：

2 如何利用sourceMap来调试或者定位咱们的错误

现代的网页愈来愈复杂，加上有babel这类的工具来对咱们写的Js代码转译，而后有uglify这类工具进行压缩，最后咱们看到的代码与原先的代码相差将会很大，单纯靠打印调试是效率极低的，因而这个时候sourceMap这个功能便应运而生。

在这里咱们结合最火爆的打包工具webpack来讲说若是利用webpack的sourcemap功能来调试以及定位错误的位置。

首先使用chrome调试带有sourcemap功能的js文件须要有下面的条件：

1. chrome开启支持sourcemap的功能
2. 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便可，以下图：

因而在终端会打印出下面的红框中的重要的一行话：

Debugger listening on port 5859.
[1] Warning: This is an experimental feature and could change at any time. [1] To start debugging, open the following URL in Chrome: [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调试得配置一下：

使用以下的调试配置：

{
  // Use IntelliSense to learn about possible Node.js debug attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Attach to Process", "type": "node", "protocol": "inspector", "request": "attach", "address": "localhost", "port": 5859 } ] } 

其中端口的配置记得和以前打印的调试端口一致，这里都是5859。

而后启动你的Nodejs服务，接着按下F5，就能够进入调试状态，打上断点，一样能够查看本地变量/堆栈等等信息。以下图：

参考

1. Devtool
2. Node.js Debugging in VS Code
3. Node Debug Architecture