詳しくはwebpack 5.Webpackの一般的な構成(下)

皆さん、こんにちは!私は大根です.前編ではentryとoutputに関する構成を紹介しましたが、この編ではWebpackの他の重要な構成を紹介します.
resolve
Webpackが構築されると、エントリファイル(entry)から各モジュールの依存を探します.resolve構成は、Webpackが依存モジュールを検索するのに役立ちます.resolveの構成により、Webpackが依存を迅速に検索したり、対応する依存(開発環境用devバージョンのlibなど)を置き換えたりすることができます.一般的なresolve構成について説明します.
1.resolve.extensions
resolve.extensionsはWebpackの拡張子の解析を支援する構成で、デフォルト値:['.wasm','.mjs','.js','.json']なので、jsとjsonファイルを導入し、拡張子を書かなくてもいいです.通常は追加できます.css、.lessなどですが、同じディレクトリの下に重複するcssやjsファイルがないことを確認し、存在する場合はパスを全部書きましょう.

module.exports = {
  resolve: {
      extensions: [‘.js’, ‘.json’, ‘.css’]
  }
}

2. resolve.alias
resolve.aliasは最も一般的な構成であり、aliasを設定することでwebpackがモジュール依存性をより迅速に検索し、コードの作成をより便利にすることができます.たとえば、実際の開発では、ソースコードをsrcフォルダに格納することがよくあります.ディレクトリ構造は次のとおりです.

src 
├── lib 
│ └── utils.js 
└── pages 
└── demo 
└── index.js

src/pages/demo/index.jsでsrc/lib/utilsを参照する場合.jsでは、:import utils from'..//./lib/utils'は、ディレクトリがより深くなるとますます見苦しくなります.aliasを設定することで、次のような書き方を短縮できます.

module.exports = {
  resolve: {
      src: path.resolve(__dirname, ‘src’),
     ‘@lib’: path.resolve(__dirname, ‘src/lib’)
  }
}

aliasが設定されている場合、ディレクトリ構造を無視して、require('@lib/utils')またはrequire('src/lib/utils')を直接使用して、Webpackのモジュールの位置決めを支援することができます.Tips:aliasの名前は@!~これらの特殊な文字は、実際の使用ではaliasが1つ、または異なるタイプで1つ使用され、通常のモジュール導入と区別され、認識度を高めることができます.
3. resolve.mainFields
いくつかのモジュールは、ES 5とES 6の2つのコードを提供するか、ブラウザ環境とnodejs環境の2つのコードを提供するなど、異なるホスト環境に対していくつかのコードを提供する.jsonファイルでは、次のように構成されます.

{
    ‘jsnext:main’: ‘es/index.js’, //  ES6         
    ‘main’: ‘lib/index.js’, //  ES5         ，node
    ‘brower’: ‘lib/web.js’ //             
}

Webpackではresolveに従います.mainFieldsの設定は、どのバージョンのモジュールコードを先に使用するかを決定します.mainFieldsのデフォルト設定は次のとおりです.

module.exports = {
    resolve: {
     mainFields: [‘brower’, ‘main’, ‘jsnext:main]
    }
}

Webpackは配列の順番でpackageにあります.jsonファイルで探して、見つけた1番目のファイルしか使いません.ES 6のコードを優先的に採用したい場合は、次のように構成できます.

module.exports = {
    resolve: {
        mainFields: [‘jsnext:main, ‘main’, ‘brower’]
    }
}

以下は、一般的ではない、または比較的簡単な構成です.

resolve.mainFiles:ディレクトリを解析するときのデフォルトファイル名、デフォルトはindex、つまりディレクトリの下を検索します.

index+resolve.extensionsファイル;

resolve.modules:モジュール依存を検索する場合、デフォルトはnode_modules;

resolve.Symlinks:適合リンク(ソフト接続、symlink)を解析するかどうか;

resolve.plugins:解析プラグイン、配列フォーマットを追加します.

resolve.CachePredicate:booleanとfunctionをキャッシュするかどうか、サポートします.functionはpathとrequireのあるオブジェクトを転送し、boolean値を返さなければなりません.

module
Webpack解析モジュールと同時に、異なるモジュールは異なるタイプのモジュールプロセッサを使用して処理する必要があります.この部分の設定はmodule構成にあります.moduleには2つの構成があります:module.noParseとmodule.rules.
1. module.noParse
module.NoParseプロファイルは、Webpackがモジュール化されていないファイルの再帰的な解析と処理を無視できるようにします.これにより、構築性能が向上し、受信タイプが正規表現、または正規表現配列、または受信モジュールパスパラメータの関数になります.

module.exports = {
    module: {
        //        
        noParse: /jquery|loadsh/
        //     
        noParse: (content) => {
            // content            
            //    true    false
            return /jquery|loadsh/.test(content);
        }
    }
}

Tips:ここでは、削除されたモジュールコードにimport、require、defineなどの内容が含まれていないことを確認し、webpackを保証します.
のパッケージにはすべてのモジュールが含まれています.そうしないと、パッケージされたjsがモジュールが不足しているため、エラーが発生します.
2.parser制御モジュール化構文
Webpackはモジュール化されたJavaScriptファイルを入口としているため,モジュール化JavaScriptの解析機能を内蔵している.AMD、Commonjs、SystemJs、ES 6をサポートします.parseプロパティは、どのモジュール構文を解析するか、解析しないかをより細かく構成できます.簡単に言えばparserを設定すると.commonjs=falseでは、コードにcommonjsのrequire構文を使用してモジュールを導入します.対応するモジュールは依存に解析されず、処理されません.サポートされるオプションは次のとおりです.

module: {
    rules: [{
        test: /\.js$/,
        use: [‘babel-loader’],
        parser: {
            amd: false, //    AMD
            commonjs: false, //    CommonJS
            system: false, //    SystemJS
            harmony: false, //    ES6 import/export
            requireInclude: false, //    require.include
            requireEnsure: false, //    require.ensure
            requireContext: false, //    require.context
            requireJs: false, //    requirejs
            browserrify: false //    browserify

        }
    }]
}

Tips:parserは構文レベルの制限であり、noParseはどのファイルが解析されないかを制御するしかありません.
3.module.rules
module.rulesはモジュールを処理する際に、ルール条件に合致するモジュールを対応するプロセッサに提出して処理し、通常loaderを構成するために使用され、そのタイプは配列であり、配列の各項目はファイルの一部をどのように処理するかを説明している.各ruleは、次の3つの部分で構成できます.

条件マッチング:test、include、excludeなどの構成によってルールを適用できるモジュールファイルにヒットする.

適用ルール:一致条件が通過したモジュールに対してuse構成項目を使用してloaderを適用し、1つのloaderを適用するか、または後から前への順序で1組の

を適用することができる.

loader、もちろん、対応するloaderにそれぞれ異なるパラメータを入力することもできます.

順序をリセットします.loaderのセットの実行順序は、デフォルトでは後から前(または右から左)まで実行され、enforceオプションでloaderの1つの実行順序を最前(pre)または最後(post)に配置できます.

4.条件マッチング
前述したように、条件マッチングに関連する構成はtest、include、exclude、resource、resourceQuery、issuerである.条件が一致するオブジェクトには、resource、resourceQuery、issuerの3種類があります.

resource:要求ファイルの絶対パス.resolveルールに基づいて解析されています.

issuer:要求されたリソース(requested the resource)のモジュールファイルの絶対パス、すなわちインポート時の場所.

例としてapp.jsインポート'./style.css?inline':

resourceは/path/to/styleです.css;

resourceQueryは?その後のinline;

issuerは/path/to/appである.js.

さらに例を挙げると、次のruleの構成項目は、srcフォルダとtestフォルダからnode_を含まないことを条件として一致します.modulesとbower_modulesサブディレクトリ、モジュールのファイルパスは.tsxと.jsxの最後のファイル.

{
    test: [/\.jsx?$/, /\.tsx?$/],
    include: [
      path.resolve(__dirname, ‘src’),
      path.resolve(__dirname, ‘test’)
    ],
    exclude: [
     path.resolve(__dirname, ‘node_modules’),
     path.resolve(__dirname, ‘brower_modules’)
    ]
}

loader構成
Loaderは解析プロセッサで、loaderによってES 6構文のjsをES 5構文に変換することができ、画像をbase 64のdataURLに変換することができ、JavaScriptファイルで直接import cssとhtmlも対応するloaderによって実現される.対応するloaderを使用する前に、JavaScriptにlessを導入する場合はless-loaderをインストールする必要があります.

npm i -D less-loader

そしてmoduleでrulesで*を指定します.lessファイルはすべてless-loaderを使用します.

Module.exports = {
    Module: {
        Rules: [
          Test: /\.less$/,
          Use: ‘less-loader’
        ]
    }
}

上記の構成を簡単に理解する、test項目の使用/.less$/正則は処理するモジュールファイル(すなわちless接尾辞のファイル)に一致し、less-loaderに渡して処理します.ここでless-loaderはstringであり、最終的にはrequire()のパラメータとして直接使用されます.これにより、lessファイルはless-loaderによって対応するcssファイルに処理されます.
1.Loaderのパラメータ
loaderにパラメータを渡す方法は2つあります.

はoptionsを介して入力される.

はqueryによって転送されます.//optionsによるmodule:{

   rules: [{
       test: /\.html$/,
       use: [{
           loader: ‘html-loader’,
           options: {
               minimize: true,
               removeComments: false,
               collapseWhitespace: false
           }
        }]
   }]

}//queyrによるmodule:{

    rules: [{
        test: /\.html$/,
        use: [{
           loader: ‘html-loader?Minimize=true&removeComments=false&collapseWhitespace=false’,
        }]
    }]

}

Pluginプラグイン
PluginはWebpackの重要な構成部分であり、pluginによってloaderでは解決できない問題を解決することができる.Webpack自体は多くのプラグインで構成されているので、多くのプラグインが内蔵されています.私たちは直接webpackオブジェクトの属性を通じて直接使用することができます.例:webpack.optimize.UglifyJsPlugin

Module.exports = {
    // ...
    Plugins: [
    //    js
       New webpack.optimize.UglifyJsPlugin()
    ]
}

内蔵プラグインのほか、NPMパッケージでもプラグインを使用できます.

//       
const ExtractTextPlugin = require(‘extract-text-webpack-plugin’);

Tips:loaderは、あるモジュールまたはあるクラスのモジュールの問題を解決するために向いていますが、pluginはプロジェクト全体に向いており、loaderでは解決できない問題を解決しています.
小結
この記事では、Webpackのentryとoutput以外の基本構成項目について説明します.ここでは、プロジェクトが常に構成されており、重要な構成項目のリストをまとめ、内容を復習します.

resolve:モジュール依存ルックアップ関連構成;

resolve.extensions:解析拡張子の構成を省略することができ、構成が多すぎるとかえってwebpack解析効率が低下する.

resolve.alias:aliasを設定することで、webpackがモジュール依存をより速く検索し、コードの書くときの相対的な経路の書くことを簡素化することができます.

module.rules:loader関連の構成、各ruleの重要な内容は:

test:処理するモジュールファイルに正則的に一致する;use:loader配列構成、内部にloaderとoptionsがあります.
include:含む;Exclude:除外;

plugins:プラグイン.