它處理的是資料夾，不是單一檔案

JSCompress 是一支免費工具，把前端的資源整批壓縮、混淆加密與合併。這句話裡有意思的詞是「整批」。壓縮一個檔案是有十幾種解法的老問題；讓三百個檔案在每次改動之後都維持壓縮狀態，才是真實專案裡真正會出錯的那一半。

它獨立執行，不掛進編輯器，也不掛進建置腳本。這是一個刻意的位置：一個裝著腳本與樣式的資料夾，可以在一台完全沒有開發環境的機器上被壓縮 —— 而那台機器，往往正是發行版被組出來的地方。

一個介面下面有兩套引擎

樣式交給 YUI Compressor for .Net，腳本交給 Google Closure Compiler。用兩套引擎而不是一套，不是猶豫 —— 這兩種語言需要不同的處理。壓縮 CSS 主要是處理空白、註解與重複，而且結果必須還是瀏覽器解析得了的樣式表。壓縮 JavaScript 是另一回事：除了空白，識別字可以縮短、到不了的程式碼可以移除，而結果的行為必須和原本完全一致 —— 這個要求比它看起來嚴格得多。

採用既有的引擎，也是它避開手寫壓縮器典型失敗的方式：一支只會刪換行的工具很好寫，然後在遇到第一個正規表示式時就把它弄壞。

流程就是四個決定

設定是每種檔案類型各選一次，在一個對話框裡決定：腳本、樣式、圖片與前處理樣式表各用哪一種壓縮方式。接下來的工作從資料夾開始：在它上面按右鍵，選「壓縮此目錄的檔案」。

還剩兩個問題，兩個都要緊。第一個是深度 —— 只處理這一層的檔案，還是連底下所有子目錄一起。第二個是這一次要包含哪些檔案類型。然後壓縮開始，一個本來要花一個下午反覆存檔的資料夾，會在讀完日誌的時間裡結束。

編碼，整批工具翻車的地方

任何會重寫原始碼檔案的工具，都必須知道它們當初是怎麼寫的。一個累積了好幾年的資料夾裡，檔案可能有多種編碼；而假設其中一種的壓縮器，會把其他編碼裡的字串全部弄壞。編碼偵測不炫，但它決定了「這批執行結果可以信」與「之後還得一個檔案一個檔案檢查」之間的差別。

同樣的顧慮也適用在合併這一步：把幾個腳本接成一個檔案，只有在「前一個的最後一行」與「後一個的第一行」不會湊成兩邊都沒說過的東西時，才成立。

它說失敗的時候，通常是對的

去壓縮一個已經壓縮過的檔案，結果可能是報錯而不是更小的檔案。這不是要繞過的臭蟲：壓縮後的程式碼已經不是引擎期待的那份原始碼，把同一個轉換跑第二次，可能改變行為，或產出解析不了的東西。

實務上的規矩，也正是這支工具圍繞著設計的那一條：留著原始碼，把壓縮結果放到另一個地方，並且把壓縮產物當成產品，而不是當成可以再編輯的東西。

它適合哪裡

JSCompress 是給「前端靠手工組起來」或「建置流程是別人維護、沒人想動」的情況用的。它是一支有視窗的整批工具，不是建置系統：它不監看檔案、不解析相依關係，也不取代任務執行器。它做的是收下一個目錄、還回一個更小的目錄，外加一份說明了發生什麼事的日誌 —— 而那往往就是全部的需求。