我所知道的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