Explication détaillée des exemples de construction et d'optimisation de packaging React et Webpack

Cet article présente principalement une brève discussion sur la construction et l'optimisation du packaging de React + Webpack. L'éditeur pense qu'il est plutôt bon, je vais donc le partager avec vous maintenant et le donner comme référence. Suivons l'éditeur et jetons un œil. J'espère que cela pourra aider tout le monde.

Utilisez babel-react-optimize pour optimiser le code React

Vérifiez les bibliothèques inutilisées et supprimez les références d'importation

Emballez les classes utilisées selon les besoins des bibliothèques, telles que comme lodash, echart, etc.

lodash peut être optimisé à l'aide de babel-plugin-lodash.

Il est à noter que

utilise le plugin babel-plugin-transform-react-remove-prop-types dans babel-react-optimize. Normalement, si vous ne faites pas référence aux PropTypes du composant dans votre code, tout va bien. L'utilisation de ce plugin peut poser des problèmes si votre composant l'utilise.

Pour plus de détails, voir :

https://github.com/oliviertassinari/babel-plugin-transform-react-remove-prop-types#is-it-safe

Build et optimisation du package Webpack

Les problèmes liés à la build et au package Webpack se concentrent principalement sur les deux aspects suivants :

1. La vitesse de construction du Webpack est lent

2. La taille du fichier après l'empaquetage du Webpack est trop grande

La vitesse de construction du Webpack est lente

Vous pouvez utiliser Webpack.DDLPlugin, HappyPack pour améliorer la vitesse de construction. Pour plus de détails, veuillez vous référer à la documentation de Xiaoming sur DMP DDLPlugin. Le texte original est le suivant :

Webpack.DLLPlugin

L'ajout d'un webpack.dll.config.js
utilise principalement un plug-in DllPlugin pour empaqueter certaines ressources tierces de manière indépendante et mettez-les dans le fichier de configuration In a manifest.json,

afin que ces ressources tierces ne soient pas reconstruites après mise à jour dans le composant,

1. et configurez les dll /vendors indépendamment en même temps, fichier .js, fourni à webpack.dll.config.js

2. Modifier package.json

Ajouter : "dll" dans les scripts : "webpack --config webpack.dll.config.js --progress --colors ", .

Après avoir exécuté npm run dll, deux fichiers supplier-manifest.json et supplier.dll.js seront produits dans le répertoire dll

Configurez le fichier webpack.dev.config.js et. ajoutez un plug-in DllReferencePlugin et spécifiez le fichier supplier-manifest.json

new webpack.DllReferencePlugin({
 context: join(__dirname, 'src'),
 manifest: require('./dll/vendor-manifest.json')
})

modify html

<% if(htmlWebpackPlugin.options.NODE_ENV ===&#39;development&#39;){ %>
 <script src="dll/vendor.dll.js"></script>
<% } %>

Notez que le paramètre NODE_ENV doit être configuré dans le plugin htmlWebpackPlugin

Happypack

Améliorer l'efficacité de la reconstruction grâce au multi-threading, mise en cache, etc. https://github.com/amireh/happypack

Créez plusieurs HappyPacks pour différentes ressources dans webpack.dev.config.js, comme 1 js, 1 de moins, et définissez l'identifiant

new HappyPack({
 id: 'js',
 threadPool: happyThreadPool,
 cache: true,
 verbose: true,
 loaders: ['babel-loader?babelrc&cacheDirectory=true'],
}),
new HappyPack({
 id: 'less',
 threadPool: happyThreadPool,
 cache: true,
 verbose: true,
 loaders: ['css-loader', 'less-loader'],
})

Configurer l'utilisation dans module.rules sur happypack/loader, définir l'identifiant

{
 test: /\.js$/,
 use: [
 'happypack/loader?id=js'
 ],
 exclude: /node_modules/
}, {
 test: /\.less$/,
 loader: extractLess.extract({
 use: ['happypack/loader?id=less'],
 fallback: 'style-loader'
 })
}

Réduire la taille du fichier après l'emballage du Webpack

Nous devons d'abord analyser l'ensemble de notre bundle, de quoi il se compose et la taille de chaque composant.

Webpack-bundle-analyzer est recommandé ici. Après l'installation, ajoutez simplement le plug-in dans webpack.dev.config.js, et les résultats de l'analyse seront automatiquement ouverts sur le site Web après chaque démarrage, comme indiqué ci-dessous

plugins.push( new BundleAnalyzerPlugin());

De plus, vous pouvez également générer le processus d'emballage dans un fichier json

webpack --profile --json -> stats.json

Ensuite, accédez à ce qui suit deux sites Web pour l'analyse

1. webpack/analyse

2. Webpack Chart

Vous pouvez le voir clairement grâce à l'analyse graphique ci-dessus, les composants de l'ensemble bundle.js et leurs tailles correspondantes.

La solution au problème de la taille excessive du bundle.js est la suivante :

1. Activez la compression et les autres plug-ins dans l'environnement de production, et supprimez les plug-ins inutiles. ins

2. Diviser le code métier, les bibliothèques tierces et les modules publics

3. Webpack active la compression gzip

4. Charger à la demande

Activer la compression et d'autres plug-ins dans l'environnement de production et supprimer les plug-ins inutiles

Assurez-vous de démarrer webpack.DefinePlugin et webpack .optimize.UglifyJsPlugin dans l’environnement de production.

const plugins = [
 new webpack.DefinePlugin({
  'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV || 'production')
 }),
  new webpack.optimize.UglifyJsPlugin({
  compress: {
   warnings: false,
   drop_console: false //eslint-disable-line
  }
  })   
]

Diviser le code métier avec des bibliothèques tierces et des modules publics

En raison de la fréquence élevée du code métier changements dans le projet, tandis que les changements de code des bibliothèques tierces sont relativement rares. Si le code métier et la troisième bibliothèque sont regroupés dans le même morceau, à chaque build, même si le code métier ne change qu'une seule ligne, même si le code de la bibliothèque tierce ne change pas, le hachage de l'ensemble du morceau sera être différent de la dernière fois. Ce n’est pas le résultat que nous souhaitons. Ce que nous voulons, c'est que si le code de la bibliothèque tierce ne change pas, nous devons alors nous assurer que le hachage correspondant ne change pas lors de la construction, afin que nous puissions utiliser le cache du navigateur pour mieux améliorer les performances de chargement des pages et raccourcir le chargement des pages. temps.

因此可以将第三库的代码单独拆分成 vendor chunk，与业务代码分离。这样就算业务代码再怎么发生变化，只要第三方库代码没有发生变化，对应的 hash 就不变。

首先 entry 配置两个 app 和 vendor 两个chunk

entry: {
 vendor: [path.join(__dirname, 'dll', 'vendors.js')],
 app: [path.join(__dirname, 'src/index')]
},
output: {
 path: path.resolve(__dirname, 'build'),
 filename: '[name].[chunkhash:8].js'
},

其中 vendros.js 是自己定义的哪些第三方库需要纳入 vendor 中，如下：

require('babel-polyfill');
require('classnames');
require('intl');
require('isomorphic-fetch');
require('react');
require('react-dom');
require('immutable');
require('redux');

然后通过 CommonsChunkPlugin 拆分第三库

plugins.push(
 // 拆分第三方库
 new webpack.optimize.CommonsChunkPlugin({ name: 'vendor' }),
 // 拆分 webpack 自身代码
 new webpack.optimize.CommonsChunkPlugin({
  name: 'runtime',
  minChunks: Infinity
 })
);

上面的配置有两个细节需要注意

1. 使用 chunkhash 而不用 hash

2. 单独拆分 webpack 自身代码

使用 chunkhash 而不用 hash

先来看看这二者有何区别：

1. hash 是 build-specific ，任何一个文件的改动都会导致编译的结果不同，适用于开发阶段

2. chunkhash 是 chunk-specific ，是根据每个 chunk 的内容计算出的 hash，适用于生产

因此为了保证第三方库不变的情况下，对应的 vendor.js 的 hash 也要保持不变，我们再 output.filename 中采用了 chunkhash

单独拆分 webpack 自身代码

Webpack 有个已知问题：

webpack 自身的 boilerplate 和 manifest 代码可能在每次编译时都会变化。

这导致我们只是在 入口文件 改了一行代码，但编译出的 vendor 和 entry chunk 都变了，因为它们自身都包含这部分代码。

这是不合理的，因为实际上我们的第三方库的代码没变，vendor 不应该在我们业务代码变化时发生变化。

因此我们需要将 webpack 这部分代码分离抽离

new webpack.optimize.CommonsChunkPlugin({
   name: "runtime",
   minChunks: Infinity
}),

其中的 name 只要不在 entry 即可，通常使用 "runtime" 或 "manifest" 。

另外一个参数 minChunks 表示：在传入公共chunk(commons chunk) 之前所需要包含的最少数量的 chunks。数量必须大于等于2，或者少于等于 chunks的数量，传入 Infinity 会马上生成 公共chunk，但里面没有模块。

拆分公共资源

同 上面的拆分第三方库一样，拆分公共资源可以将公用的模块单独打出一个 chunk，你可以设置 minChunk 来选择是共用多少次模块才将它们抽离。配置如下：

new webpack.optimize.CommonsChunkPlugin({
 name: 'common',
 minChunks: 2,
}),

是否需要进行这一步优化可以自行根据项目的业务复用度来判断。

开启 gzip

使用 CompressionPlugin 插件开启 gzip 即可：

// 添加 gzip
new CompressionPlugin({
 asset: '[path].gz[query]',
 algorithm: 'gzip',
 test: /\.(js|html)$/,
 threshold: 10240,
 minRatio: 0.8
})

大家学会了吗？赶紧动手尝试一下吧。

相关推荐：

parcel.js打包出错到选择nvm的全部过程解析

Parcel打包示例详解

webpack多入口文件页面打包详解

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!