Chargeurs Webpack vs plugins; quelle est la différence?

Quelle est la différence entre les chargeurs et les plugins dans Webpack?

La documentation des plugins dit simplement:

Utilisez des plugins pour ajouter des fonctionnalités généralement liées aux bundles dans webpack.

Je sais que babel utilise un chargeur pour les transformations jsx / es2015, mais il semble que d'autres tâches courantes (copy-webpack-plugin, par exemple) utilisent des plugins à la place.

Les chargeurs effectuent la transformation de prétraitement de pratiquement tous les formats de fichiers lorsque vous utilisez sth comme require("my-loader!./my-awesome-module")dans votre code. Comparés aux plugins, ils sont assez simples car ils (a) n'exposent qu'une seule fonction à webpack et (b) ne sont pas capables d'influencer le processus de construction réel.

Les plugins, d'un autre côté, peuvent s'intégrer profondément dans webpack car ils peuvent enregistrer des hooks dans le système de construction de webpacks et accéder (et modifier) ​​le compilateur, et son fonctionnement, ainsi que la compilation. Par conséquent, ils sont plus puissants, mais aussi plus difficiles à entretenir.

Ajout de réponse complémentaire et plus simple.

Chargeurs:

Les chargeurs fonctionnent au niveau du fichier individuel pendant ou avant la génération du bundle .

Plugins:

Les plugins fonctionnent au niveau du bundle ou du fragment et fonctionnent généralement à la fin du processus de génération du bundle. Les plugins peuvent également modifier la façon dont les bundles eux-mêmes sont créés. Les plugins ont un contrôle plus puissant que les chargeurs.

Juste pour un exemple, vous pouvez clairement voir dans l'image ci-dessous où les chargeurs fonctionnent et où les plugins fonctionnent -

Références: article et image

À la base, webpack n'est qu'un regroupeur de fichiers. Considérant un scénario très simple (pas de fractionnement de code), cela pourrait signifier uniquement les actions suivantes (à un niveau élevé):

1. trouver le fichier d'entrée et charger son contenu en mémoire
2. faire correspondre certains textes dans le contenu et évaluer ceux-ci (par exemple @import)
3. trouver les dépendances sur la base d'une évaluation précédente et faire de même avec elles
4. les assembler tous en un paquet en mémoire
5. écrire les résultats dans le système de fichiers

Lorsque vous examinez attentivement les étapes ci-dessus, cela résonne avec ce que fait un compilateur Java (ou n'importe quel compilateur). Il y a des différences bien sûr, mais cela n'a pas d'importance pour comprendre les chargeurs et les plugins.

Chargeurs:

sont là parce que webpack promet de regrouper tous les types de fichiers.

Étant donné que webpack à sa base n'est que suffisamment capable de regrouper des fichiers js, cette promesse signifiait que l'équipe principale de webpack devait incorporer des flux de construction qui permettaient au code externe de transformer un type de fichier particulier d'une manière que Webpack pourrait consommer.

Ces codes externes sont appelés chargeurs et s'exécutent généralement au cours des étapes 1 et 3 ci-dessus. Ainsi, étant donné que l'étape à laquelle ces chargeurs doivent s'exécuter est évidente, ils ne nécessitent pas de hooks et n'influencent pas non plus le processus de construction (puisque la construction ou le bundle ne se produit qu'à l'étape 4).

Les chargeurs préparent donc la phase de compilation et étendent en quelque sorte la flexibilité du compilateur Webpack.

Plugins:

sont ici parce que même si webpack ne promet pas directement une sortie variable, le monde le veut et webpack le permet.

Étant donné que Webpack, à sa base, n'est qu'un bundler et qu'il passe par plusieurs étapes et sous-étapes pour ce faire, ces étapes peuvent être utilisées pour intégrer des fonctionnalités supplémentaires.

Le processus de construction de production (minification et écriture dans le système de fichiers), qui est une capacité native du compilateur webpack, par exemple, peut être traité comme une extension de sa capacité principale (qui est juste un regroupement) et peut être traité comme un plugin natif. S'ils ne l'avaient pas fourni, quelqu'un d'autre l'aurait fait.

En regardant le plugin natif ci-dessus, il semble que le regroupement ou la compilation du pack Web peut être décomposé en processus de regroupement principal, plus de nombreux processus de plug-in natifs que nous pouvons désactiver, personnaliser ou étendre. Cela signifiait permettre au code externe de se joindre au processus de regroupement à des points spécifiques parmi lesquels ils pouvaient choisir (appelés hooks).

Les plugins influencent donc la sortie et étendent en quelque sorte la capacité du compilateur webpack.

Les chargeurs fonctionnent au niveau du fichier . Ils peuvent écrire un modèle, traiter du code pour le transpiler selon votre convenance, etc.

Les plugins fonctionnent au niveau du système . Ils peuvent travailler sur le modèle, la gestion du système de fichiers (nom, chemin), etc.