概覽#

Sources 面板可說是 Chrome DevTools Debug 流程的主舞台。當問題的複雜度超過 Console 面板與 Elements 面板能夠處理的範圍，Sources 面板就是接手場面的工具。

打開 Sources 面板後，整個視窗大致分為左、中、右三個區域：

• 左側：和當前頁面相關的資源樹，包含 HTML、CSS、JavaScript 等已載入檔案，並以資料夾結構呈現。
• 中間：檔案內容顯示區，編輯也在這裡進行，可以根據需求把左右兩側收合來放大這個區塊。
• 右側：JavaScript Debugger，上方是 Debug 操作按鈕，下方則是執行環境資訊，與斷點（Breakpoint）、單步執行（Step Over / Step Into / Step Out）、變數監看搭配使用。

在進入面板的各種功能之前，必須先理解兩件事：Source Map 與 File Editing。

Source Map#

為什麼需要 Source Map#

現代前端幾乎都離不開框架，瀏覽器最終執行的 JavaScript 通常和開發時看到的原始碼差距很大，原因來自於下列幾類處理工具：

這些工具讓我們能使用尚未被瀏覽器支援的語法、JSX，或合併、壓縮資源以提升效能。但相對的代價是：經過多道處理後的程式碼，幾乎沒有 Debug 價值，變數名稱、行號完全錯位。

Source Map 就是為了解決這個問題誕生的。它建立一份「轉換後程式碼」對應「原始碼」的位置對照表，讓錯誤訊息、調用堆疊（Call Stack）、行號可以被反向映射回開發者熟悉的原始檔。

Source Map 不只能用在 JavaScript，被 Bundler 或 SASS 處理過的 CSS 也同樣適用。

運作原理#

Source Map 的本質是一份字元位置對照表，並把這份對照表的路徑寫在實際執行的檔案中讓瀏覽器讀取。產出 Source Map 大致經過下列步驟：

• 將原始碼打包成單行執行碼。
• 把原始碼中的所有變數名稱蒐集起來放進陣列。
• 把執行碼的每個字元位置對應到原始碼的行號與變數陣列索引。
• 以 VLQ 與 Base64 編碼後產出最終的 Source Map 檔案。

當網頁中的程式碼丟出錯誤時，瀏覽器讀取 Source Map 後便能把錯誤位置映射回原始檔，並允許開發者在原始檔上加入斷點來 Debug。

想完整了解 VLQ 編碼與 Source Map 規範細節，原文中提供了 Microsoft 的實作說明文章與 Google 的 Source Map 規格文件（一份 Google Docs）連結，值得閱讀。

File Editing#

File Editing 讓你直接在 DevTools 裡修改頁面的檔案，幾乎是把 Chrome DevTools 當成一個輕量 IDE 在使用。基本流程很單純：

• 打開 Sources 面板的 Page 頁籤。
• 點開 index.js 或其他想修改的檔案。
• 編輯內容後按 Command+S 存檔。

存檔之後，頁面行為會立刻反映你的修改。對於想要快速試水溫、調樣式、改邏輯的情境很方便。

不過 File Editing 有兩個要特別留意的地方：

• 不能編輯 HTML，只能改 JavaScript 與 CSS。
• 修改後雖然會看到生效，但檔名旁會出現驚嘆號圖示，提示這份修改沒有寫回檔案系統，重整頁面後就會消失。

// 在 DevTools 直接修改 greet 後存檔，行為立即改變
function greet(name) {
  return `Hi, ${name}!`;
}

File Editing 的修改不會被保存到檔案系統（File System Access），只在當次瀏覽期間生效。要真正留住修改，必須改用 Workspace 中的 Filesystem 或 Overrides 功能。

小結#

Source Map 是 Sources 面板裡無聲卻關鍵的角色，常見的 Bundler（例如 Webpack）都提供 Source Map 相關設定，可依環境選擇是否產出，以及採用哪一種 Source Map 模式。

而最早期的 File Editing 在新版 Chrome DevTools 已不再以獨立頁籤存在，取而代之的是 Filesystem 與 Overrides 兩個功能，會在下一章中詳細介紹。

原文出處#

• 原書/iThome：https://ithelp.ithome.com.tw/articles/10242922 ^↗