Webpack の最適化構成に関連する問題-jsチュートリアル-php.cn

この記事では主にWebpackの最適化に関する知識を紹介します - ファイル検索範囲を絞り込み、最適化する方法を詳しく紹介します。ファイル内の import ステートメントを入力して分析し、再帰的に解析します。

import ステートメントに遭遇すると、Webpack は次の 2 つのことを行います:

1. import ステートメントに従って、インポートされる対応するファイルを検索します。たとえば、require('react') import ステートメントに対応するファイルは ./node_modules/react/react.js で、require('./util') に対応するファイルは ./util.js です。

2. インポートするファイルの見つかったサフィックスに基づいて、設定内のローダーを使用してファイルを処理します。たとえば、ES6 を使用して開発された JavaScript ファイルは、babel-loader を使用して処理する必要があります。

上記の2つはファイルの処理としては非常に高速ですが、プロジェクトが大きくなるとファイル数も非常に多くなり、ビルド速度が遅いという問題が露呈します。

上記の 2 つは避けることはできませんが、速度を上げるためには最小限に抑える必要があります。

以下では、最適化する方法を一つずつ紹介していきます。

ローダー構成を最適化するローダーによるファイルの変換操作には時間がかかるため、ローダーで処理できるファイルをできるだけ少なくする必要があります。

2-3 モジュールでは、ローダーを使用するときに、テスト、インクルード、除外の 3 つの構成項目を使用して、ローダーがルールを適用したいファイルをヒットできることを紹介しました。

ローダーによって処理されるファイルをできるだけ少なくするために、 include を使用して、処理する必要があるファイルのみをターゲットにすることができます。

Babel-loader を設定するときに、ES6 を使用するプロジェクトを例に挙げます。

module.exports = {
 module: {
  rules: [
   {
    // 如果项目源码中只有 js 文件就不要写成 /\.jsx?$/，提升正则表达式性能
    test: /\.js$/,
    // babel-loader 支持缓存转换出的结果，通过 cacheDirectory 选项开启
    use: [&#39;babel-loader?cacheDirectory&#39;],
    // 只对项目根目录下的 src 目录中的文件采用 babel-loader
    include: path.resolve(__dirname, &#39;src&#39;),
   },
  ]
 },
};

ログイン後にコピー

Loader を設定するときに、include を通じてヒット範囲を絞りやすくするために、プロジェクトのディレクトリ構造を適切に調整できます。

resolve.modules 構成の最適化2-4 の解決で紹介されましたresolve.modules は、Webpack がサードパーティモジュールを検索するディレクトリを構成するために使用されます。

resolve.modules のデフォルト値は

です。これは、まず現在のディレクトリの ./node_modules ディレクトリに移動して、探しているモジュールを見つけることを意味します。見つからない場合は、上位レベルのディレクトリに移動します。 ../node_modules にアクセスして見つけます。見つからない場合は、../../node_modules に移動します。これは、Node.js のモジュール検索メカニズムとよく似ています。

['node_modules'] インストールされたサードパーティモジュールがすべてプロジェクトルートディレクトリの ./node_modules ディレクトリに配置されている場合、デフォルトの方法でレイヤごとに検索する必要はありません。サードパーティモジュールを保存する絶対パスを指定できます。構成は次のとおりです:

module.exports = {
 resolve: {
  // 使用绝对路径指明第三方模块存放的位置，以减少搜索步骤
  // 其中 __dirname 表示当前工作目录，也就是项目根目录
  modules: [path.resolve(__dirname, &#39;node_modules&#39;)]
 },
};

ログイン後にコピー

resolve.mainFields 構成を最適化します 2-4 Resolve で導入された、resolve.mainFields は、サードパーティモジュールによって使用されるエントリファイルを構成するために使用されます。

インストールされたサードパーティモジュールには、モジュールのプロパティを記述するための package.json ファイルが存在します。いくつかのフィールドは、エントリファイルの場所を記述するために使用されます。エントリーファイルの説明。

エントリーファイルを記述するフィールドが複数存在できる理由は、一部のモジュールは複数の環境で同時に使用でき、動作環境ごとに異なるコードを使用する必要があるためです。

isomorphic-fetch を例に挙げると、これはフェッチ API の実装ですが、ブラウザーと Node.js 環境の両方で使用できます。

その package.json には 2 つのエントリファイル説明フィールドがあります:

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

ログイン後にコピー

isomorphic-fetch は、ブラウザーではネイティブ fetch または XMLHttpRequest 実装を介してフェッチ API の実装メカニズムが異なるため、異なる実行環境で異なるコードを使用します。、http モジュールを通じて Node.js に実装されます。

resolve.mainFields のデフォルト値は、現在のターゲット設定に関連しています。対応関係は次のとおりです。

検索手順を減らすために、サードパーティモジュールのエントリファイルの説明フィールドを指定する場合、できるだけ少なく設定できます。

ほとんどのサードパーティモジュールはメインフィールドを使用してエントリファイルの場所を記述するため、Webpack は次のように構成できます:

module.exports = {
 resolve: {
  // 只采用 main 字段作为入口文件描述字段，以减少搜索步骤
  mainFields: [&#39;main&#39;],
 },
};

ログイン後にコピー

この方法を使用して最適化する場合は、すべてのサードパーティモジュールのエントリファイル記述フィールドを考慮する必要があります。 -ランタイムが依存するパーティモジュール。1 つのモジュールが間違っている場合でも、ビルドされたコードは正しく実行されない可能性があります。

resolve.alias 構成の最適化2-4 解決で導入された、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 文件，从而跳过耗时的递归解析操作。