Si les dépendances de chaque module du projet sont considérées comme une arborescence, alors l'entrée est la racine de l'arborescence des dépendances.
Ces modules dépendants seront encapsulés dans un morceau lors de l'empaquetage. Alors, qu’est-ce qu’un morceau ?
Chunk signifie littéralement bloc de code, qui dans Webpack peut être compris comme des modules qui ont été abstraits et empaquetés. C'est comme un sac de fichiers contenant de nombreux fichiers. Les fichiers à l'intérieur sont chaque module qui ajoute une couche d'emballage à l'extérieur pour former un morceau :
En fonction de la configuration spécifique, un ou plusieurs morceaux peuvent être générés lorsqu'un projet est empaqueté.
Plusieurs entrées peuvent être définies dans le projet, et chaque entrée générera une ressource de résultat.
Par exemple, il y a deux entrées dans notre projet, src/index.js
et src/lib.js
dist/index.js
et dist/lib.js
.
Dans certains cas particuliers, une entrée peut générer plusieurs morceaux et finalement plusieurs
Paramètres :
module.exports = { Entry:'./src/index.js', //Indique le fichier d'entrée, c'est-à-dire entrer dans notre projet à partir d'index.js};①Exemple de type
d'entrée
signifiant | chaîne | ' |
---|---|---|
./app/entry | ' | Le chemin du fichier de l'entrée module, qui peut être |
un tableau | de chemin relatif['./app/entry1', './app/entry2'] | Le chemin de fichier du module d'entrée, qui peut être un |
objet | de chemin relatif{ a: './app/entry- a', b : ['./ app/entry-b1', './app/entry-b2']} | Configurez plusieurs entrées, chaque entrée génère un morceau |
s'il s'agit d'un type de tableau, lorsqu'elle est utilisée avec la sortie. élément de configuration de la bibliothèque, uniquement le dernier du tableau Le module du fichier d'entrée sera exporté
② Nom du Chunk
Webpack donnera un nom à chaque Chunk généré Le nom du Chunk est lié à la configuration de l'Entrée :
③Dynamique de configuration d'entrée
S'il y a plusieurs pages dans le projet, vous devez configurer une entrée pour chaque page d'entrée, mais le nombre de ces pages peut continuer à croître, puis la configuration d'Entrée. sera affecté par d’autres facteurs et ne peut pas être écrit sous forme de valeur statique. La solution est de définir l'Entrée dans une fonction pour renvoyer dynamiquement la configuration mentionnée ci-dessus. Le code est le suivant :
// Entrée de fonction synchrone : () => {. retour { a:'./pages/a', b:'./pages/b', } } ; // Entrée de fonction asynchrone : () => { renvoyer une nouvelle promesse ((résolve) => { résoudre({ a:'./pages/a', b:'./pages/b', }); }); };
Paramètre : contexte
Webpack utilisera le contexte comme répertoire racine lors de la recherche de fichiers avec des chemins relatifs . Le contexte est par défaut le répertoire de travail actuel dans lequel Webpack est démarré. Si vous souhaitez modifier la configuration par défaut du contexte, vous pouvez la définir comme ceci dans le fichier de configuration :
module.exports = { contexte : chemin.resolve(__dirname, 'app') }
Notez que le contexte doit être une chaîne de chemin absolu.
De plus, vous pouvez également définir laen apportant le paramètre webpack --context lors du démarrage de Webpack.
Utilisation : entry:string|Array<string>
1. Syntaxe abrégée
webpack.config.js
//Comme il est unique, il peut être abrégé comme suit : module.exports = { entrée : './main.js' };
La configuration d'entrée ci-dessus est en fait écrite sous l'abréviation suivante
module.exports = { entrée : { principal : './main.js' } };
2. Syntaxe du tableau
module.exports = { entrée : { principal :['./main.js','./main2.js'] } };
La fonction de transmission d'un tableau est de fusionner plusieurs ressources à l'avance. Lors de l'empaquetage, Webpack utilisera le dernier élément du tableau comme chemin d'entrée réel.
Lors de l'utilisation d'une chaîne ou d'un tableau pour définir une seule entrée, il n'y en a pas. moyen de changer le nom du morceau, ne peut être que le "principal" par défaut.
Utilisation : entry: {[entryChunkName: string]: string|Array}
Syntaxe des objets
module.exports = { entrée : { application : './src/app.js', fournisseurs : './src/vendors.js' } };
Ce sera plus fastidieux. Cependant, il s'agit de la manière la plus extensible de définir des points d'entrée dans une application.
"Configuration webpack extensible" : réutilisable et combinable avec d'autres configurations. Il s'agit d'une technique populaire pour séparer les préoccupations de l'environnement, de la cible de construction et du temps d'exécution. Fusionnez-les ensuite à l’aide d’outils spécialisés comme webpack-merge.
1. Les applications monopage
, qu'il s'agisse de frameworks, de bibliothèques ou de modules sur chaque page, sont référencées par un point d'entrée unique de app.js
L'avantage est qu'un seul fichier JS sera généré et les dépendances seront claires .
module.exports = { entrée : './src/app.js' };
Cette approche présente également des inconvénients, c'est-à-dire que tous les modules sont regroupés ensemble. Lorsque l'échelle de l'application augmente jusqu'à un certain niveau, le volume de ressources généré sera trop important, ce qui réduira la vitesse de rendu des pages de l'utilisateur
. configuration de Webpack, lorsqu'un bundle est plus grand qu'à 250 Ko (avant compression), le bundle sera considéré comme trop volumineux, et un avertissement se produira lors du packaging, comme le montre la figure :
2. Séparez la bibliothèque tierce (fournisseur)
Afin de résoudre le problème ci-dessus, vous pouvez extraire la bibliothèque tierce (fournisseur).
Dans Webpack, le fournisseur fait généralement référence à des tiers tels que des bibliothèques . et les frameworks utilisés par le projet. Bundle
module.exports = { entrée : { application : './src/app.js', fournisseurs : ['react','react-dom','react-router'], } };
Sur la base de l'exemple d'application, nous avons ajouté une nouvelle entrée avec le nom de bloc vendor
et mis les modules tiers dont dépend le projet sous la forme d'un tableau.
Nous n'avons pas défini le chemin d'entrée pour le fournisseur. . Que doit faire Webpack ?
À l'heure actuelle, nous pouvons utiliser CommonsChunkPlugin (CommonsChunkPlugin a été abandonné après Webpack 4, vous pouvez utiliser optimisation.splitChunks) pour extraire les modules communs dans les deux morceaux d'application et de fournisseur.
Avec cette configuration, le bundle généré par app.js sera uniquement. contenir Le module métier et les modules tiers dont il dépend seront extraits pour générer un nouveau bundle, ce qui atteint également notre objectif d'extraire le fournisseur.
Puisque le fournisseur ne contient que des modules tiers, cette partie ne changera pas fréquemment. Par conséquent, la mise en cache côté client peut être utilisée efficacement, ce qui accélérera la vitesse de rendu globale lorsque l'utilisateur demandera ensuite la page.
CommonsChunkPlugin est principalement utilisé pour extraire des bibliothèques tierces et des modules publics afin d'éviter que les fichiers groupés chargés sur le premier écran ou les fichiers groupés chargés à la demande ne soient trop volumineux, ce qui entraîne des temps de chargement longs.
3. Application multipage
Pour les scénarios d'application multipage, afin de réduire autant que possible la taille des ressources, nous espérons que chaque page ne charge que sa propre logique nécessaire, plutôt que de regrouper toutes les pages dans le même bundle. Par conséquent, chaque page a besoin d'un ensemble indépendant . Dans ce cas, nous utilisons plusieurs entrées pour y parvenir. Veuillez consulter l'exemple suivant :
module.exports = { entrée : { pageOne : './src/pageOne/index.js', pageDeux : './src/pageTwo/index.js', pageTrois : './src/pageThree/index.js' } };
La configuration ci-dessus indique à webpack qu'il a besoin de 3 graphiques de dépendances indépendants et séparés. À ce stade, l'entrée et la page sont en correspondance biunivoque, afin que chaque HTML puisse charger les modules dont il a besoin tant qu'il l'introduit. son propre JS.