我們都知道webpack的配置文件 webpack.config.js 文件中 mode 表示webpack當前的環境以及對不同的環境的配置。雖然官方文檔寫明瞭三種不同的模塊的配置，但是沒有具體說明是什麼意思，我就註釋一下對應的模塊到底進行了什麼操作。
development（開發模式）
下面是從官方上得到的開發模式的全部配置，
// webpack.development.config.js
module.exports = {
+ mode: 'development', // mode的默認配置就是production，就是說如果你不配置mode默認值是生產模式
- devtool: 'eval', // 控制如何生成source-map，默認配置是不生成source-map，eval值是在bundle文件中每個模塊都使用 eval() 執行
- cache: true, // 緩存生成的 webpack 模塊和 chunk，默認只有在watch模式下啓用
- performance: {
- hints: false // 配置如何展示性能提示。例如，如果一個資源超過 250kb，webpack 會對此輸出一個警告來通知你。值有：false | "error" | "warning"，此屬性默認設置爲 "warning"。
- },
- output: {
- pathinfo: true // 告知 webpack 在 bundle 中引入「所包含模塊信息」的相關注釋。此選項在 development 模式時的默認值是 true，而在 production 模式時的默認值是 false。
- },
- optimization: { //
- namedModules: true, // 告知 webpack 使用可讀取模塊標識符(readable module identifiers)，來幫助更好地調試。webpack 配置中如果沒有設置此選項，默認會在 mode development 啓用，在 mode production 禁用。與下面new webpack.NamedModulesPluginn()插件效果相同。
- namedChunks: true, // ？？？告知 webpack 使用可讀取 chunk 標識符(readable chunk identifiers)，來幫助更好地調試。webpack 配置中如果沒有設置此選項，默認會在 mode development 啓用，在 mode production 禁用。
- nodeEnv: 'development', // nodeEnv使用DefaultPlugin將字符串設置給process.env.NODE_ENV，除非設置爲false，默認值是mode的值
- splitChunks: {
- hidePathInfo: false, // ？？？
- minSize: 10000, // 生成chunk的最小大小（以字節爲單位），默認爲30000
- maxAsyncRequests: Infinity, // 按需加載時並行請求的最大數量，默認爲5
- maxInitialRequests: Infinity, // 入口的最大並行請求數。默認爲3
- },
- },
- plugins: [
- new webpack.NamedModulesPlugin(), // 過時，webpack4中建議使用optimization.namedModules來實現相同的效果
- new webpack.NamedChunksPlugin(), // 過時，webpack4中建議使用optimization.namedChunks來實現相同的效果
- new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("development") }), // 與上面的nodeEnv參數效果一樣
- ]
}
production（生產模式）
待補充
devtool和sourcemap相關介紹
JavaScript Source Map 詳解（阮一峯的網絡日誌）
這個文章對source map的由來，生成map文件都進行了詳細的說明。
Webpack中的sourcemap
這篇文章則重點是webpack上的sourcemap的生成，分析了devtool配置項目中的eval，inline，module，cheap關鍵字對sourcemap生成的影響，好文章，強烈推薦！
就我在上面文章基礎上的理解是：eval確實是一種不同於生成.map文件的源碼映射方法，它是一種映射在源碼和壓縮代碼中間的方法，它映射的代碼是經過webpack處理，但是又能看出源碼一定模樣的代碼，雖然行數對應有問題，但是確定問題代碼位置一般沒有問題。適用於模塊是自己寫的項目中使用，如果模塊不是自己寫就不要使用eval相關模式生成的sourcemap了，找錯代碼更危險。
下面給出在chrome瀏覽器訪問的eval源碼的文件與實際源碼的區別：
// eval文件中的源碼
__webpack_require__.r(__webpack_exports__);
/* harmony export (binding) */ __webpack_require__.d(__webpack_exports__, "default", function() { return printMe; });
function printMe() {
console.log("I get called from printfffff.js");
// console.error("I get called from print.js");
}
// 實際的源碼
export default function printMe() {
console.log("I get called from printfffff.js");
// console.error("I get called from print.js");
}
output中的pathinfo參數是否開啓的區別
下面依次是output中pathinfo爲false和true時生成的bundle文件中的差異：bundle文件中包含的模塊（文件）的註釋信息，主要是文件對外暴露的方法名。
optimization.namedModules參數是否開啓的區別
optimization.namedModules參數主要是控制 webpack 使用可讀取模塊標識符(readable module identifiers)，來幫助更好地調試代碼。目前在官方的例子上是使用在模塊熱替換這個功能中打印熱替換時對應替換模塊的id轉成對應文件的名字。
下面是對應參數開啓和關閉時效果的例子：
如果有其它使用的場景，歡迎交流，共同提高。