為什麼我們要做三份 Webpack 配置檔案

發表於2017-09-28

v2-428e325a87d01d02923ad2ed4c3e785a_r在知乎上我們常常會看到有同學發問:BAT 等大型網站的前端工程是如何組織管理的?這的確是一個可以發散的很廣的 Q&A,我想如果要我回答這個問題,不如先從 Webpack 配置說起。

時至今日,Webpack 已經成為前端工程必備的基礎工具之一,不僅被廣泛用於前端工程釋出前的打包,還在開發中擔當本地前端資源伺服器(assets server)、模組熱更新(hot module replacement)、API Proxy 等角色,結合 ESLint 等程式碼檢查工具,還可以實現在對原始碼的嚴格校驗檢查。

正如上文中提到的,前端從開發到部署前都離不開 Webpack 的參與,而 Webpack 的預設配置檔案只有一個,即 webpack.config.js,那麼問題來了,開發期和部署前應該使用同一份 Webpack 配置嗎?答案肯定是否定的,既然 webpack.config.js 是一個 JS 檔案,我們當然可以在檔案裡寫 JavaScript 業務邏輯,通過讀取環境變數 NODE_ENV 來判斷當前是在開發(dev)時還是最終的生產環境(production),然而很多同學習慣把這兩者的配置都混寫在根目錄下的 webpack.config.js,通過很多零散的 if…else 來“臨時”決定某一個 plugin 或者某一個 loader 的配置項,隨著 loaders 和 plugins 的不斷增加,久而久之 webpack.config.js 變得原來越隆長,程式碼的可讀性和可維護性也大大下降。

我想通過本文來介紹一種用 3 個 JS 檔案來配置 Webpack 的方法,這裡借鑑了很多開源專案的配置,同時也結合了我們自己在開發中碰到的種種問題解決方案。

本文中提及的配置基於 Webpack 2 或以上,建議使用 3.0 及以上版本


開發環境與生產環境的區別

開發環境

  • NODE_ENV 為 development
  • 啟用模組熱更新(hot module replacement)
  • 額外的 webpack-dev-server 配置項,API Proxy 配置項
  • 輸出 Sourcemap

生產環境

  • NODE_ENV 為 production
  • 將 React、jQuery 等常用庫設定為 external,直接採用 CDN 線上的版本
  • 樣式原始檔(如 css、less、scss 等)需要通過 ExtractTextPlugin 獨立抽取成 css 檔案
  • 啟用 post-css
  • 啟用 optimize-minimize(如 uglify 等)
  • 中大型的商業網站生產環境下,是絕對不能有 console.log() 的,所以要為 babel 配置 Remove console transform

這裡需要說明的是因為開發環境下啟用了 hot module replacement,為了讓樣式原始檔的修改也同樣能被熱替換,不能使用 ExtractTextPlugin,而轉為隨 JS Bundle 一起輸出。


你需要三份配置檔案

1. webpack.base.config.js

在 base 檔案裡,你需要將開發環境和生產環境中通用的配置集中放在這裡:

2. webpack.dev.config.js

這是用於開發環境的 Webpack 配置,繼承自 base:

3. webpack.config.js

這是用於生產環境的 webpack 配置,同樣繼承自 base:


現在在你的工程資料夾裡應該已經有三個 Webpack 配置檔案,它們分別是:

  • webpack.base.config.js
  • webpack.dev.config.js
  • webpack.config.js

最後,你還需要在 package.json 裡新增相應的配置:

和很多專案一樣,在開發環境下的時候,你需要使用 npm run dev 來啟動,而在生產環境中,則用 npm run build 來發布。

題外話,在真實場景中,我們不會直接使用 webpack-dev-server,而採用 express + webpack/webpack-dev-middleware,配置方法與上面所述的完全相同。

相關文章