Auparavant, j'utilisais le plugin webpack common chunks pour créer des bundles de fournisseurs contenant des bibliothèques tierces comme angular, react, lodash etc, mais ensuite j'ai connu le plugin webpack dll. Ils semblent faire les mêmes choses mais le plugin dll vous permet également de réduire le temps de construction. Je ne sais pas si je dois utiliser ces deux plugins ensemble. Dois-je utiliser le plugin common chunks pour créer le vendor bundle dans le build de production et le plugin dll dans le build de développement. Ou dois-je utiliser le plugin dll à la fois dans les builds de production et de développement ? Pouvez-vous m'expliquer cela ?
Réponses
Trop de publicités?
Désolé pour cette longue réponse, mais espérons qu'elle puisse aider à rendre les choses plus claires.
Raison d'être de CommonsChunkPlugin
L'auteur du projet définit un certain nombre de points d'entrée de l'application qui produiront chacun un paquet. Des exemples typiques sont vendeur , polyfills , principal Mais par exemple, votre application pourrait être divisée en plusieurs "zones" indépendantes qu'il serait logique de charger séparément (comme par exemple la connexion, la partie principale, les paramètres).
L'auteur du projet définit ensuite lequel de ces paquets, ou un paquet distinct, doit contenir le code commun à tous ces paquets. Il s'agit généralement de bibliothèques tierces et de vos propres utilitaires partagés entre tous les points d'entrée.
Il incombe alors au plugin d'analyser et de collecter ce code commun, puis de le mettre dans une liasse définie. Toute cette analyse et ce travail se répètent à chaque fois que vous démarrez une nouvelle compilation, et - en mode veille - lorsque vous modifiez du code qui est partagé et qui se trouve être dans un bundle commun.
Une telle division est utile aussi bien pour une construction de développement que pour une construction de production. Mais pour l'environnement de développement, disons simplement que la reconstruction du code lié aux vendeurs et aux polyfills peut prendre un certain temps et que cela peut être un gaspillage si vous ne changez pas vraiment ces parties (en supposant que le code tiers dont vous dépendez est plus important que votre propre base de code).
Raison d'être de DllPlugin
Étant donné le même environnement, par exemple le développement, l'auteur du projet crée deux configurations webpack là où il n'y en avait qu'une. Le plugin pourrait être appliqué à l'environnement de production, bien que l'on puisse dire que DllPlugin a plus de sens en développement (voir ci-dessous).
La première configuration de construction de webpack est nécessaire pour ce qu'on appelle DLLs qui sont assez proches du code commun vu précédemment, mais pas exactement. D'après ce que j'ai compris, les DLL ont tendance à regrouper le code de tiers (fournisseur et polyfills) et non votre propre code utilitaire partagé, mais là encore, il s'agit plutôt d'une impression et non d'une règle stricte. Quoi qu'il en soit, l'auteur du projet devrait ici regrouper le code qui change beaucoup moins fréquemment au cours d'une session de développement normale. L'idée, dans un environnement de développement, est de lancer cette construction de temps en temps, par exemple lorsqu'une dépendance change. En général, c'est au développeur de lancer ce build quand il le juge nécessaire.
L'autre configuration de construction de webpack est nécessaire pour le code propre au projet, ou de toute façon le code qui change régulièrement pendant le travail de développement. Il s'agit de la construction réelle que le développeur exécutera encore et encore, ou qu'il exécutera en mode veille, et à ce stade, elle devrait être beaucoup plus rapide que la construction unique vue dans le scénario CommonsChunk.
Donc, dans l'ensemble, ils semblent similaires, mais ils vous permettent d'atteindre des cibles différentes. À tel point que vous pourriez envisager d'utiliser DllPlugin pour votre environnement de développement (avantage : temps de compilation court), tout en utilisant CommonsChunkPlugin pour la production (avantage : temps de chargement court lorsque l'application change). Encore une fois, vous pourriez tout aussi bien utiliser DllPlugin en production, avec le petit inconvénient de devoir lancer deux constructions d'affilée : une pour les DLLs, puis une pour l'application.
HTH
user981375
Points
398
Vous utilisez l'un ou l'autre. Voici un article qui décrit comment utiliser DllPlugin et, en bas de la page, vous pouvez voir d'autres méthodes pour accomplir la même chose. Il vous indique les différences, ainsi que les avantages et les inconvénients. Cela devrait vous aider à démarrer.
adam-beck
Points
2526
Je cherchais la différence ici aussi mais je ne pense vraiment pas que ce soit le cas. Du moins, plus maintenant.
Si vous jetez un coup d'œil à la documentation sur le webpack pour les bibliothèques de découpage de code, il mentionne un moyen d'extraire un fichier manifeste similaire. D'après ce que j'ai compris, c'est ce que fait le DllPlugin, sauf que c'est légèrement plus implicite avec le CommonsChunkPlugin.
L'avantage est que vous n'avez pas besoin de maintenir plusieurs configurations de Webpack pour ce type de fonctionnalité.
