Pourquoi séparer les bibliothèques tierces ?

Webpack est un petit gobelin ennuyeux. J'ai toujours été dans le camp de la surabondance et j'ai utilisé Browserify pour l'empaquetage. J'ai découvert que Webpack avait explosé en popularité. J'avais peur d'être laissé pour compte par la communauté, alors je l'ai rapidement repris et j'ai joué avec. Au départ, je voulais juste jouer. Après avoir essayé de créer un package, je souhaite démarrer un serveur Webpack, puis ajouter un remplacement à chaud, séparer les fichiers CSS, utiliser divers chargeurs pour traiter et optimiser les résultats du package, et quelles sont les différences entre les différentes cartes sources ? manquant. Lors de l’ajout du remplacement à chaud, il y a eu quelques rebondissements car le serveur d’applications et le serveur webpack n’utilisaient pas le même. Ensuite, nous arrivons au sujet d’aujourd’hui.
Étape par étape pour élargir le sujet d'aujourd'hui :
Pourquoi devrions-nous séparer les bibliothèques tierces ?
Cet avantage est évident. La bibliothèque tierce est relativement stable et ne changera pas facilement après avoir utilisé le cache du navigateur, les utilisateurs chargeant à nouveau la page réduiront les requêtes du serveur et amélioreront l'expérience d'optimisation de la vitesse. La fonction d'extraction de modules communs de plusieurs applications (entrées) est similaire. Les parties communes seront mises en cache et toutes les applications peuvent utiliser le contenu mis en cache pour améliorer les performances.
Puis-je utiliser le navigateur pour modifier le cache en séparant la bibliothèque tierce ?
C'est aussi évidemment négatif. Il existe de nombreux facteurs qui conduisent à l'impossibilité d'utiliser le cache. Par exemple, le plus évident est que chaque fois que vous reconditionnez le fichier de bibliothèque séparé, il peut recevoir un nom différent. . C'est plus facile à trouver. Un autre exemple est que des collègues en arrière-plan définissent le délai d'expiration du cache pour le fichier js sur 0. C'est embarrassant, mais s'il est 0, le cache ne peut pas être utilisé ? Non, tant que le fichier est totalement inchangé, notez qu'il est totalement inchangé, y compris l'heure de modification, le cache sera toujours utilisé et les performances monteront en flèche. Si vous souhaitez utiliser la mise en cache, vous devez d'abord comprendre la mise en cache. Voici une brève mention :
Quel est le mécanisme de mise en cache du navigateur ?
La stratégie donnée par HTTP1.1 est d'utiliser Cache-control avec Etag
Exemple de paramètre de contrôle de cache :
'Cache-Control' : 'public, max-age=600',
max-age est le délai d'expiration. S'il a expiré, il vérifiera également l'Etag
La valeur de ETag :
Dans Apache, la valeur par défaut de ETag est le nœud d'index (INode). size (Size) et L'heure de la dernière modification (MTime) est obtenue après hachage.
Si l'Etag est le même, de nouvelles ressources ne seront toujours pas demandées, mais le fichier précédent sera utilisé.
À quoi sert exactement CommonsChunkPlugin ?
Compris littéralement, extraire le package public. Le package public signifie qu'il est utilisé à plus d'un endroit. La bibliothèque d'une application monopage (entrée unique) n'est utilisée que par lui-même, elle ne peut donc pas l'être. considéré comme un package public, n'est-ce pas ? Le package public extrait par ce plug-in sera reconditionné à chaque fois (Etag sera différent), que ce soit pour gagner du temps de packaging (même si c'est trivial mais cela ne sert à rien après tout : la bibliothèque n'a pas changé du tout), ou pour utiliser le cache du navigateur (abandonneriez-vous la mise en cache si l'âge maximum expire ?) Ce n'est pas non plus une bonne solution. La meilleure solution a émergé : DllPlugin
Quels sont les avantages de DllPlugin ?
Emballez le fichier de bibliothèque une seule fois. En d'autres termes, tant que le fichier de bibliothèque reste inchangé, vous ne devez le empaqueter qu'une seule fois. Peu importe si vous empaquetez le code métier et le fichier de bibliothèque ultérieurement. De cette manière, le fichier de bibliothèque sera toujours la même bibliothèque. Tant que le fichier de la bibliothèque reste inchangé, le cache sera toujours valide (Etag reste inchangé), faites le sac et oubliez la bibliothèque en vous sentant rafraîchi. Permettez-moi de vous présenter la façon la plus simple de l'utiliser :
Écrivez d'abord un autre fichier de configuration Webpack. Après tout, il s'agit d'une bibliothèque de packages distincte. Supposons que webpack.config.dll.js

.

const path = require('path')const webpack = require('webpack');module.exports = {
  entry: {vendor: ['react', 'react-dom', 'react-hot-loader', 'immutable', 'redux', 'react-redux', 'react-router-dom', 'redux-logger',  'redux-persist', 'redux-persist-transform-immutable', 'redux-thunk'],
  },
  output: {filename: 'js/[name].js',path: path.resolve(__dirname, 'public'),library: '[name]', // 当前Dll的所有内容都会存放在这个参数指定变量名的一个全局变量下，注意与DllPlugin的name参数保持一致
  },
  plugins: [new webpack.DllPlugin({  path: path.resolve(__dirname, 'public/manifest.json'), // 本Dll文件中各模块的索引，供DllReferencePlugin读取使用  name: '[name]',}),
  ],}

Ajouter le plug-in DllReferencePlugin dans le fichier de configuration d'origine Le fichier est empaqueté en premier Tant que la bibliothèque reste inchangée, ce package sera utilisé à l'avenir, et. Ensuite, le code métier est empaqueté et le travail est terminé.

Stratégie recommandée :

new webpack.DllReferencePlugin({  manifest: require('./public/manifest.json'), // 指定manifest.json  name: 'vendor',  // 当前Dll的所有内容都会存放在这个参数指定变量名的一个全局变量下，注意与DllPlugin的name参数保持一致}),

Chacun fait son propre truc.

S'il s'agit d'une application d'une seule page, utilisez simplement DllPlugin pour empaqueter le fichier de bibliothèque, et le code métier peut être empaqueté dans un seul paquet.
S'il s'agit d'une application multipage, une fois que DllPlugin a empaqueté les fichiers de la bibliothèque, de nombreux codes commerciaux publics peuvent être utilisés pendant le développement et peuvent changer à tout moment. Dans ce cas, CommonsChunkPlugin doit être utilisé pour faire ce qu'il est. censé faire, puis extraire le code commercial public. En ce qui concerne la mise en cache, au moins les parties publiques seront toujours mises en cache lors du passage d'une page à l'autre. webpack -p --progress --config ./webpack.config.dll.js

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!