Webpack如何優化配置縮小文件搜索范圍

這篇文章將為大家詳細講解有關Webpack如何優化配置縮小文件搜索范圍，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

Webpack 啟動后會從配置的 Entry 出發，解析出文件中的導入語句，再遞歸的解析。

在遇到導入語句時 Webpack 會做兩件事情：

1.根據導入語句去尋找對應的要導入的文件。例如 require('react') 導入語句對應的文件是 ./node_modules/react/react.js ， require('./util') 對應的文件是 ./util.js 。

2.根據找到的要導入文件的后綴，使用配置中的 Loader 去處理文件。例如使用 ES6 開發的 JavaScript 文件需要使用 babel-loader 去處理。

以上兩件事情雖然對于處理一個文件非常快，但是當項目大了以后文件量會變的非常多，這時候構建速度慢的問題就會暴露出來。

雖然以上兩件事情無法避免，但需要盡量減少以上兩件事情的發生，以提高速度。

接下來一一介紹可以優化它們的途徑。

優化 loader 配置

由于 Loader 對文件的轉換操作很耗時，需要讓盡可能少的文件被 Loader 處理。

在 2-3 Module 中介紹過在使用 Loader 時可以通過 test 、 include 、 exclude 三個配置項來命中 Loader 要應用規則的文件。

為了盡可能少的讓文件被 Loader 處理，可以通過 include 去命中只有哪些文件需要被處理。

以采用 ES6 的項目為例，在配置 babel-loader 時，可以這樣：

module.exports = {
 module: {
  rules: [
   {
    // 如果項目源碼中只有 js 文件就不要寫成 /\.jsx?$/，提升正則表達式性能
    test: /\.js$/,
    // babel-loader 支持緩存轉換出的結果，通過 cacheDirectory 選項開啟
    use: ['babel-loader?cacheDirectory'],
    // 只對項目根目錄下的 src 目錄中的文件采用 babel-loader
    include: path.resolve(__dirname, 'src'),
   },
  ]
 },
};

你可以適當的調整項目的目錄結構，以方便在配置 Loader 時通過 include 去縮小命中范圍。

優化 resolve.modules 配置

在 2-4 Resolve 中介紹過 resolve.modules 用于配置 Webpack 去哪些目錄下尋找第三方模塊。

resolve.modules 的默認值是 ['node_modules'] ，含義是先去當前目錄下的 ./node_modules 目錄下去找想找的模塊，如果沒找到就去上一級目錄 ../node_modules 中找，再沒有就去 ../../node_modules 中找，以此類推，這和 Node.js 的模塊尋找機制很相似。

當安裝的第三方模塊都放在項目根目錄下的 ./node_modules 目錄下時，沒有必要按照默認的方式去一層層的尋找，可以指明存放第三方模塊的絕對路徑，以減少尋找，配置如下：

module.exports = {
 resolve: {
  // 使用絕對路徑指明第三方模塊存放的位置，以減少搜索步驟
  // 其中 __dirname 表示當前工作目錄，也就是項目根目錄
  modules: [path.resolve(__dirname, 'node_modules')]
 },
};

優化 resolve.mainFields 配置

在 2-4 Resolve 中介紹過 resolve.mainFields 用于配置第三方模塊使用哪個入口文件。

安裝的第三方模塊中都會有一個 package.json 文件用于描述這個模塊的屬性，其中有些字段用于描述入口文件在哪里， resolve.mainFields 用于配置采用哪個字段作為入口文件的描述。

可以存在多個字段描述入口文件的原因是因為有些模塊可以同時用在多個環境中，準對不同的運行環境需要使用不同的代碼。

以 isomorphic-fetch 為例，它是 fetch API 的一個實現，但可同時用于瀏覽器和 Node.js 環境。

它的 package.json 中就有2個入口文件描述字段：

{
 "browser": "fetch-npm-browserify.js",
 "main": "fetch-npm-node.js"
}

isomorphic-fetch 在不同的運行環境下使用不同的代碼是因為 fetch API 的實現機制不一樣，在瀏覽器中通過原生的 fetch 或者 XMLHttpRequest 實現，在 Node.js 中通過 http 模塊實現。

resolve.mainFields 的默認值和當前的 target 配置有關系，對應關系如下：

• 當 target 為 web 或者 webworker 時，值是 ["browser", "module", "main"]

• 當 target 為其它情況時，值是 ["module", "main"]
  

以 target 等于 web 為例，Webpack 會先采用第三方模塊中的 browser 字段去尋找模塊的入口文件，如果不存在就采用 module 字段，以此類推。

為了減少搜索步驟，在你明確第三方模塊的入口文件描述字段時，你可以把它設置的盡量少。

由于大多數第三方模塊都采用 main 字段去描述入口文件的位置，可以這樣配置 Webpack：

module.exports = {
 resolve: {
  // 只采用 main 字段作為入口文件描述字段，以減少搜索步驟
  mainFields: ['main'],
 },
};

使用本方法優化時，你需要考慮到所有運行時依賴的第三方模塊的入口文件描述字段，就算有一個模塊搞錯了都可能會造成構建出的代碼無法正常運行。

優化 resolve.alias 配置

在 2-4 Resolve 中介紹過 resolve.alias 配置項通過別名來把原導入路徑映射成一個新的導入路徑。

在實戰項目中經常會依賴一些龐大的第三方模塊，以 React 庫為例，安裝到 node_modules 目錄下的 React 庫的目錄結構如下：

├── dist
│   ├── react.js
│   └── react.min.js
├── lib
│   ... 還有幾十個文件被忽略
│   ├── LinkedStateMixin.js
│   ├── createClass.js
│   └── React.js
├── package.json
└── react.js

可以看到發布出去的 React 庫中包含兩套代碼：

• 一套是采用 CommonJS 規范的模塊化代碼，這些文件都放在 lib 目錄下，以 package.json 中指定的入口文件 react.js 為模塊的入口。

• 一套是把 React 所有相關的代碼打包好的完整代碼放到一個單獨的文件中，這些代碼沒有采用模塊化可以直接執行。其中 dist/react.js 是用于開發環境，里面包含檢查和警告的代碼。 dist/react.min.js 是用于線上環境，被最小化了。
  

默認情況下 Webpack 會從入口文件 ./node_modules/react/react.js 開始遞歸的解析和處理依賴的幾十個文件，這會時一個耗時的操作。

通過配置 resolve.alias 可以讓 Webpack 在處理 React 庫時，直接使用單獨完整的 react.min.js 文件，從而跳過耗時的遞歸解析操作。

相關 Webpack 配置如下：

module.exports = {
 resolve: {
  // 使用 alias 把導入 react 的語句換成直接使用單獨完整的 react.min.js 文件，
  // 減少耗時的遞歸解析操作
  alias: {
   'react': path.resolve(__dirname, './node_modules/react/dist/react.min.js'),
  }
 },
};

除了 React 庫外，大多數庫發布到 Npm 倉庫中時都會包含打包好的完整文件，對于這些庫你也可以對它們配置 alias。
但是對于有些庫使用本優化方法后會影響到后面要講的 使用 Tree-Shaking 去除無效代碼 的優化，因為打包好的完整文件中有部分代碼你的項目可能永遠用不上。

一般對整體性比較強的庫采用本方法優化，因為完整文件中的代碼是一個整體，每一行都是不可或缺的。

但是對于一些工具類的庫，例如 lodash ，你的項目可能只用到了其中幾個工具函數，你就不能使用本方法去優化，因為這會導致你的輸出代碼中包含很多永遠不會執行的代碼。

優化 resolve.extensions 配置

在導入語句沒帶文件后綴時，Webpack 會自動帶上后綴后去嘗試詢問文件是否存在。

在 2-4 Resolve 中介紹過 resolve.extensions 用于配置在嘗試過程中用到的后綴列表，默認是：

extensions: ['.js', '.json']

也就是說當遇到 require('./data') 這樣的導入語句時，Webpack 會先去尋找 ./data.js 文件，如果該文件不存在就去尋找 ./data.json 文件，如果還是找不到就報錯。

如果這個列表越長，或者正確的后綴在越后面，就會造成嘗試的次數越多，所以 resolve.extensions 的配置也會影響到構建的性能。

在配置 resolve.extensions 時你需要遵守以下幾點，以做到盡可能的優化構建性能：

• 后綴嘗試列表要盡可能的小，不要把項目中不可能存在的情況寫到后綴嘗試列表中。

• 頻率出現最高的文件后綴要優先放在最前面，以做到盡快的退出尋找過程。

• 在源碼中寫導入語句時，要盡可能的帶上后綴，從而可以避免尋找過程。例如在你確定的情況下把 require('./data') 寫成 require('./data.json') 。

相關 Webpack 配置如下：

module.exports = {
 resolve: {
  // 盡可能的減少后綴嘗試的可能性
  extensions: ['js'],
 },
};

優化 module.noParse 配置

在 2-3 Module 中介紹過 module.noParse 配置項可以讓 Webpack 忽略對部分沒采用模塊化的文件的遞歸解析處理，這樣做的好處是能提高構建性能。

原因是一些庫，例如 jQuery 、ChartJS， 它們龐大又沒有采用模塊化標準，讓 Webpack 去解析這些文件耗時又沒有意義。

在上面的 優化 resolve.alias 配置 中講到單獨完整的 react.min.js 文件就沒有采用模塊化，讓我們來通過配置 module.noParse 忽略對 react.min.js 文件的遞歸解析處理，

相關 Webpack 配置如下：

const path = require('path');
module.exports = {
 module: {
  // 獨完整的 `react.min.js` 文件就沒有采用模塊化，忽略對 `react.min.js` 文件的遞歸解析處理
  noParse: [/react\.min\.js$/],
 },
};

注意被忽略掉的文件里不應該包含 import 、 require 、 define 等模塊化語句，不然會導致構建出的代碼中包含無法在瀏覽器環境下執行的模塊化語句。

關于“Webpack如何優化配置縮小文件搜索范圍”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。