Partage d'expérience Webpack-tutoriel CSS-php.cn

Partage d'expérience Webpack

小云云

Libérer： 2018-02-02 14:28:06

original

1730 Les gens l'ont consulté

webpack est un bundler de modules. Son objectif principal est de regrouper des fichiers JavaScript. Les fichiers packagés sont utilisés dans les navigateurs, mais il peut également être utilisé pour la transformation, le regroupement ou le package. J'espère que certaines de mes expériences pourront vous aider.

Cache

Générer le nom du fichier [name].[contenthash:8].js, combinez max-age + cdn pour la mise en cache.

Chargement de la page Web

html

était un fichier HTML fixe, html -> numéro de version js (tapé via webpack) -> déterminer le js spécifique via la version nombre . (Cela n'a plus de sens maintenant que j'y pense, même s'il n'est pas si fortement couplé au backend)

Maintenant, c'est le code HTML modifié, qui est tapé via HtmlWebpackPlugin (généré par webpack, contenant js avec numéro de version)

De cette façon, cela permet également d'économiser une heure de série (en extrayant le fichier du numéro de version). Dans le même temps, il est également pratique d'effectuer des niveaux de gris. Par exemple, si vous publiez les exigences, laissez d'abord certains utilisateurs en faire l'expérience, puis tapez dynamiquement le code HTML et envoyez-le en arrière-plan. (Réparer le HTML n'est pas si simple)

Séparation CSS

Dans Guanmai, il y aura très peu de changements CSS, grâce à l'amélioration des noms de classe par React-gm. Comme il y a peu de changements, il n'est pas mauvais de séparer les CSS et d'utiliser ExtractTextPlugin pour séparer les CSS.

Après la séparation, la taille de js est réduite et js n'est pas bloqué. En même temps, css et js peuvent être extraits en même temps.

common

new CommonsChunkPlugin({name: 'commons'})

Copier après la connexion

En regardant le code commun emballé, vous constaterez que les identifiants et les hachages des autres modules seront tapés en commun, de sorte que le fichier commons changera à chaque fois, ce qui rend difficile la mise en cache.

Fournissez simplement deux listes de fichiers et vous constaterez que webpack place l'identifiant et le hachage dans le fichier manifeste. De cette façon, les communs peuvent être mis en cache. Au fait, je n'ai vu aucune introduction sur le site officiel, faites-moi savoir si vous le faites.

new CommonsChunkPlugin({names: ['commons', 'manifest']})

Copier après la connexion

Développement local

Parlons des agents. Les services locaux démarrent par eux-mêmes. Il n'y a pas de service d'arrière-plan, ils doivent donc naturellement être des agents quelque part. Disponible via devServer.proxy. Vous pouvez également utiliser un agent pour accéder au réseau externe afin de rechercher des bogues. Il s'agit uniquement de code source, la vérification des bogues est donc très rapide.

"proxy": {
    "/ticket/*": {
      "target": "http://dev.guanmai.cn:7413",
      "changeOrigin": true
    }
}

Copier après la connexion

Vitesse de packaging

DllPlugin

Lorsque le projet devient volumineux, il nécessitera inévitablement de nombreux packages, ce qui entraînera un temps de packaging très long. L'approche officielle recommandée consiste à transformer les fichiers qui ne changent pas fréquemment en DLL.

Notre projet fera appel à react react-dom prop-types classnames mobx mobx-react lodash moment big.js etc.

Les informations en ligne indiquent que le nom de fichier de la dll est [name]_[hash].dll.js, le nôtre est [npm version]_dll.js npm version qui est lu par la version package.json.

Pourquoi ne pas utiliser la version hash mais npm ? Nous avons rencontré un problème lors de la réflexion sur le packaging secondaire. Comment juger si la DLL doit être reconditionnée ? Que faire s'il s'agit de hachage (veuillez recommander une solution). Si vous utilisez la version npm, nous reconditionnerons dès que la version change. Par exemple, si React est mis à niveau, nous aurons la version + et le reconditionnerons.

happypack

happypack améliore considérablement la vitesse de construction. Il peut être empaqueté dans plusieurs threads et le cache accélère également la reconstruction.

devtool

eval est utilisé pour le développement et source-map est utilisé pour la production (utilisé pour résoudre les problèmes d'affichage au détriment de la vitesse d'emballage, dans une plage acceptable)

babel-loader

Rappelez-vous cacheDirectory

noParse && alias

Certaines bibliothèques n'ont pas besoin d'être analysées, la configuration noParse n'analyse pas et l'alias pointe vers x.min Fichier .js.

secouement d'arbre

Ce n'est pas encore utilisé, on a l'impression que ce n'est pas encore le bon moment. Il y a un bon article. Votre Tree-Shaking est inutile

Compression

UglifyJsPlugin

Au début, j'utilisais webpack.optimize.UglifyJsPlugin, qui était 1.x à cette fois-là, webpack est basé sur uglify-js@2.x.

Maintenant que Webpack est sorti séparément, il a également beaucoup plus de fonctions. Il prend en charge le cache et la compression multicœur. Je l'ai essayé et c'était assez rapide. webpack.optimize.UglifyJsPlugin est en fait uglifyjs-webpack-plugin.

Ce qui me surprend, c'est que le site officiel dit qu'il est basé sur uglify-es. Mais je pense que la dépendance est toujours uglify-js. étrangeté.

UglifyJsParallelPlugin

Avant la sortie officielle, j'utilisais webpack-uglify-parallel, qui prend en charge le multicœur. La vitesse n'est pas très différente de celle d'uglifyjs-webpack-plugin.

Quand j'ai écrit l'article, j'ai parcouru github et j'ai découvert qu'il avait été abandonné en juillet et intégré au site officiel.

Autres

babel-minify-webpack-plugin de babel, restez à l'écoute.

Script cdn

Certains js (gm-fetch babel-polyfill) ont très peu de changements. L'emballage avec webpack est un peu inutile. Vous pouvez l'obtenir via cdn et mettre le formulaire de script dans le. document html.