1. 從 Webpack 到 Snowpack, 編譯速度提升十倍以上——TRPG Engine遷移小記
原文地址: http://moonrailgun.com/posts/74598ef5/
TRPG Engine 經過長久以來的迭代，項目已經顯得非常臃腫了。數分鍾的全量編譯, 每次按下保存都會觸發一次 10s 到 1m 不等的增量編譯讓我苦不堪言, 龐大的依賴使其每一次編譯都會涉及很多文件和很多包，長時的編譯時間大大降低了開發效率與迭代速度。
經過一段時間的考察，我選擇了 Snowpack 作為解決方案。與 Webpack 不同的是，除了第一次的全量編譯以外， Snowpack 的增量編譯不會涉及到龐大的 node_moles 文件夾, 准確來說只會編譯變更文件本身。甚至於如果沒有對依賴進行變更，下次的全量編譯會直接動用之前編譯的文件緩存，不需要花時間等待 node_moles 的編譯。
為什麼會這么快？這是由於 Snowpack 本身的實現與設計哲學有關的。相比 Webpack , Snowpack 利用了現代瀏覽器的本身的 mole 系統，跳過復雜的模型之間的組織編譯過程而只關注於變更文件本身的編譯，這樣當然快了。
拿 Snowpack 官方的一張圖來說:
snowpack 的最我譯單位是文件，而 webpack 的最我譯單位為 chunk , 而 chunk 還需要額外的計算, 不論是編譯部分還是編譯後的組裝部分。snowpack的設計邏輯天生決定了她的速度。
優化前(使用 webpack ):
全量編譯:
增量編譯:
全量請求用時:
優化後(使用 snowpack ):
全量編譯:
增量編譯:
(看不到編譯用時，但是體感在1s內. 而且該效果在電腦運行其他應用時更加顯著)
全量請求用時:
以上測試是保證電腦在空閑時間，且保存與操作內容為同一文件
該用時已經是平時操作的最快時間，為此我的MBR重啟了一次強制清空了swap空間, 實際表現會更加顯著
因為文件依賴於瀏覽器的耗時，而瀏覽器需要串列請求依賴，因此耗時會更加長
但實際使用中使用snowpack會更加優秀。因為其相比webpack會大大節約電腦資源。在webpack編譯時會佔用大量的電腦資源，會影響到其他操作
TRPG Engine 算是非常經典的 Webpack 應用了, 使用了各種Loader。光通用配置就有250+行，各種優化配置，各種 alias。等等長時間迭代積攢下來的配置，因此毫不意外的會遇到很多問題與坑。
以下是我遇到的問題與解決方案:
Snowpack雖然作為一個新興的打包工具，目前尚不是非常完善, 功能也沒有webpack這樣豐富與齊全。但是它的新的打包設計對於有一定規模的前端應用還是非常優秀的。能極大提升開發效率。不失為一種好的解決方案。當然最後輸出還是需要使用webpack對其進行一定的優化，畢竟原生的mole支持目前瀏覽器的支持度還沒有達到覆蓋一個理想的地步 https://caniuse.com/es6-mole
最後這是我最後提交的 pr
2. 如何解決webpack打包後，dist文件過大的問題
去除不必要的插件
剛開始用 webpack 的時候，開發環境和生產環境用的是同一個 webpack 配置文件，導致生產環境打包的 JS 文件包含了一大堆沒必要的插件，比如 HotMoleReplacementPlugin, NoErrorsPlugin... 這時候不管用什麼優化方式，都沒多大效果。所以，如果你打包後的文件非常大的話，先檢查下是不是包含了這些插件。
提取第三方庫
像 react 這個庫的核心代碼就有 627 KB，這樣和我們的源代碼放在一起打包，體積肯定會很大。所以可以在 webpack 中設置
{
entry: {
bundle: 'app'
vendor: ['react']
}
plugins: {
new webpack.optimize.CommonsChunkPlugin('vendor', 'vendor.js')
}
}
這樣打包之後就會多出一個 vendor.js 文件，之後在引入我們自己的代碼之前，都要先引入這個文件。比如在 index.html 中
<script src="/build/vendor.js"></script>
<script src="/build/bundle.js"></script>
除了這種方式之外，還可以通過引用外部文件的方式引入第三方庫，比如像下面的配置
{
externals: {
'react': 'React'
}
}
externals 對象的 key 是給 require 時用的，比如 require('react')，對象的 value 表示的是如何在 global 中訪問到該對象，這里是 window.React。這時候 index.html 就變成下面這樣
<script src="//cdn.bootcss.com/react/0.14.7/react.min.js"></script>
<script src="/build/bundle.js"></script>
當然，個人更推薦第一種方式。
代碼壓縮
webpack 自帶了一個壓縮插件 UglifyJsPlugin，只需要在配置文件中引入即可。
{
plugins: [
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false
}
})
]
}
加入了這個插件之後，編譯的速度會明顯變慢，所以一般只在生產環境啟用。
另外，伺服器端還可以開啟 gzip 壓縮，優化的效果更明顯。
代碼分割
什麼是代碼分割呢？我們知道，一般載入一個網頁都會把全部的 js 代碼都載入下來。但是對於 web app 來說，我們更想要的是只載入當前 UI 的代碼，沒有點擊的部分不載入。
看起來好像挺麻煩，但是通過 webpack 的 code split 以及配合 react router 就可以方便實現。具體的例子可以看下 react router 的官方示例 huge apps。不過這里還是講下之前配置踩過的坑。
code split 是不支持 ES6 的模塊系統的，所以在導入和導出的時候千萬要注意，特別是導出。如果你導出組件的時候用 ES6 的方式，這時候不管導入是用 CommomJs 還是 AMD，都會失敗，而且還不會報錯！
當然會踩到這個坑也是因為我剛剛才用 NodeJS，而且一入門就是用 ES6 的風格。除了這個之外，還有一點也要注意，在生產環境的 webpack 配置文件中，要加上 publicPath
output: {
path: xxx,
publicPath: yyy,
filename: 'bundle.js'
}
不然的話，webpack 在載入 chunk 的時候，路徑會出錯。
設置緩存
開始這個小節之前，可以先看下大神的一篇文章：大公司里怎樣開發和部署前端代碼。
對於靜態文件，第一次獲取之後，文件內容沒改變的話，瀏覽器直接讀取緩存文件即可。那如果緩存設置過長，文件要更新怎麼辦呢？嗯，以文件內容的 MD5 作為文件名就是一個不錯的解決方案。來看下用 webpack 應該怎樣實現
output: {
path: xxx,
publicPath: yyy,
filename: '[name]-[chunkhash:6].js'
}
打包後的文件名加入了 hash 值
const bundler = webpack(config)
bundler.run((err, stats) => {
let assets = stats.toJson().assets
let name
for (let i = 0; i < assets.length; i++) {
if (assets[i].name.startsWith('main')) {
name = assets[i].name
break
}
}
fs.stat(config.buildTemplatePath, (err, stats) => {
if (err) {
fs.mkdirSync(config.buildTemplatePath)
}
writeTemplate(name)
})
})
手動調用 webpack 的 API，獲取打包後的文件名，通過 writeTemplate 更新 html 代碼。完整代碼猛戳 gitst。