不小心掉進了 uglify-js 的坑

最近，在開發一個中小規模的 web app。結果，發現每次構建的時間特別的長，要 2~3 分鐘。

為了解決這個問題，先是無腦的上了各種 happypack，parallel-uglifyjs 之類的插件，但是優化效果一般，甚至構建時間變得更長。。。配置 noParse, resolve 之類的配置，也不起作用。。。

無奈之下，開始深入 webpack 調查一下構建緩慢的真正原因。如題，問題出在了 uglify 上。如果把 uglify 的配置去掉，構建的時間就能縮短到 30 秒以內。也就是說壓縮文件花了兩分鐘，雖說 uglify 是最耗時的構建任務，但是兩分鐘時間也忒長了。。。明明代碼也沒多少。

接下來，想辦法把每個壓縮文件的處理時間打出來：

結果發現，其中有一個文件持續了 100 多秒。看來這個構建過程就是被這個文件拖慢的。這個文件也不算大，也就兩萬行的代碼量。和其他文件的唯一區別就是裡面包含了 已經壓縮了的 echarts 代碼。

最後，用 google 搜索了一下 「uglify slow minified file」，還真找到了問題，感興趣可以看一下這個 issue：Very slow processing for minified files · Issue #321 · mishoo/UglifyJS2。大概意思就是 uglify 在處理已經壓縮過的文件時，在去除 unused variables 的環節性能會很差，處理時間是正常情況下的幾十倍。

解決方案是在 UglifyJsPlugin 插件的配置當中，禁用掉 unused 選項：

new webpack.optimize.UglifyJsPlugin({ compress: { unused: false }, sourceMap: false})

這個問題也算是告一段落了。

不過還是要吐槽的是：這個 bug 是 16 年的，可是現在都 17 年了，uglifyjs 聲稱解決了這個問題，可是即便升級了 webpack 和 uglifyjs 這個問題還是沒有得到實際解決。