Webpackローダーとプラグイン。違いは何ですか？
ローダーとwebpackのプラグインの違いは何ですか？
プラグインのドキュメント ただ言う：
プラグインを使用して、通常webpackのバンドルに関連する機能を追加します。
Babelはjsx/es2015変換にローダーを使用しますが、他の一般的なタスク（たとえば、copy-webpack-plugin）は代わりにプラグインを使用するようです。
コードでrequire("my-loader!./my-awesome-module")などのsthを使用すると、ローダーは事実上すべてのファイル形式の前処理変換を行います。プラグインと比較すると、（a）1つの関数のみをwebpackに公開し、（b）実際のビルドプロセスに影響を与えることができないため、プラグインは非常に単純です。
一方、プラグインはwebpackビルドシステム内にフックを登録し、コンパイラーとその動作、コンパイルにアクセス（および変更）できるため、webpackに深く統合できます。したがって、それらはより強力ですが、維持することも困難です。
本質的に、webpackは単なるファイルバンドラーです。非常に単純なシナリオ（コード分割なし）を考えると、これは次のアクション（高レベル）を意味する可能性があります。
- エントリファイルを見つけて、その内容をメモリにロードします
- コンテンツ内の特定のテキストに一致し、それらを評価します（例：@import）
- 以前の評価に基づいて依存関係を見つけ、それらについて同じことを行います
- それらをすべてメモリ内のバンドルにステッチします
- 結果をファイルシステムに書き込む
上記の手順を詳しく調べると、これはJavaコンパイラー（または任意のコンパイラー）が行うことと共鳴します。もちろん違いはありますが、ローダーとプラグインを理解することは重要ではありません。
ローダー：
これは、webpackがすべてのファイルタイプをバンドルすることを約束しているためです。
Webpackのコアはjsファイルをバンドルできるだけの能力があるため、この約束により、webpackコアチームはビルドフローを組み込み、外部コードがwebpackが消費できる方法で特定のファイルタイプを変換できるようにする必要がありました。
これらの外部コードはローダーと呼ばれ、通常は上記の手順1および3で実行されます。したがって、これらのローダーを実行する必要がある段階は明らかであるため、フックを必要とせず、ビルドプロセスにも影響しません（ビルドまたはバンドルはステップ4でのみ発生するため）。
そのため、ローダーはコンパイルのステージを準備し、webpackコンパイラーの柔軟性を拡張します。
プラグイン：
なぜなら、webpackは変数の出力を直接約束していなくても、世界はそれを望んでおり、webpackはそれを許可しているからです。
中核のwebpackは単なるバンドル機能でありながら、いくつかのステップとサブステップを実行するため、これらのステップを利用して追加機能を組み込むことができます。
たとえば、webpackコンパイラのネイティブ機能であるプロダクションビルドプロセス（ファイルシステムへの縮小および書き込み）は、コア機能（単なるバンドル）の拡張として処理でき、ネイティブプラグインのように処理できます。彼らがそれを提供していなかったら、他の誰かがそれをしていたでしょう。
上記のネイティブプラグインを見ると、まるでwebpackのバンドルまたはコンパイルがコアバンドルプロセスに分割できるように見えます。さらに、多くのネイティブプラグインプロセスをオフまたはカスタマイズまたは拡張できます。これは、外部コードが選択可能な特定のポイント（フックと呼ばれる）でバンドリングプロセスに参加できるようにすることを意味しました。
したがって、プラグインは出力に影響し、webpackコンパイラの機能を拡張します。