Detailed explanation of React and Webpack construction and packaging optimization examples

This article mainly introduces a brief discussion of React + Webpack construction and packaging optimization. The editor thinks it is quite good. Now I will share it with you and give it as a reference. Let’s follow the editor to take a look, I hope it can help everyone.

Use babel-react-optimize to optimize React code

Check unused libraries and remove import references

Package the classes used as needed Libraries, such as lodash, echart, etc.

lodash can be optimized using babel-plugin-lodash.

It should be noted that

The babel-plugin-transform-react-remove-prop-types plugin is used in babel-react-optimize. Normally, if you don't reference the component's PropTypes in your code, it's totally fine. Using this plugin may cause problems if your component uses it.

See:

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

Webpack build and package optimization

The problems in Webpack build and package mainly focus on the following two aspects:

1. Webpack build speed is slow

2. The file size after Webpack package is too large

Webpack build speed is slow

You can use Webpack.DDLPlugin, HappyPack to improve build speed. For details, please refer to Xiaoming’s documentation on DMP DDLPlugin. The original text is as follows:

Webpack.DLLPlugin

Adding a webpack.dll.config.js
mainly uses a DllPlugin plug-in to independently package some third-party resources and place them at the same time In a manifest.json configuration file,

In this way, after updating in the component, these third-party resources will not be rebuilt,

1. At the same time, configure dll/vendors independently .js file, provided to webpack.dll.config.js

2. Modify package.json

Add: "dll": "webpack --config webpack.dll.config.js --progress --colors ", .

After executing npm run dll, two files vendor-manifest.json and vendor.dll.js will be generated in the dll directory.

Configure the webpack.dev.config.js file and add one DllReferencePlugin plug-in, and specify the vendor-manifest.json file

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>
<% } %>

Note, you need to configure the NODE_ENV parameter in the htmlWebpackPlugin plug-in

Happypack

Improve rebuild efficiency through multi-threading, caching, etc. https://github.com/amireh/ happypack

Create multiple HappyPacks for different resources in webpack.dev.config.js, such as 1 js, 1 less, and set the id

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'],
})

Configure use in module.rules to happypack/loader, set the id

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

Reduce the file size after Webpack packaging Size

First we need to analyze our entire bundle, what it consists of and the size of each component.

Webpack-bundle-analyzer is recommended here. After installation, just add the plug-in in webpack.dev.config.js, and the analysis results will be automatically opened on the website after each startup, as shown below

plugins.push( new BundleAnalyzerPlugin());

In addition, you can also output the packaging process into a json file

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

Then go to the following two websites for analysis

1. webpack/analyse

2. Webpack Chart

It can be clearly seen from the above chart analysis that the entire bundle .js components and corresponding sizes.

The solution to the excessive size of bundle.js is as follows:

1. Enable compression and other plug-ins in the production environment and remove unnecessary plug-ins

2. Split business code and third-party libraries and public modules

3. webpack Enable gzip compression

4. Load on demand

Enable compression and other plug-ins in the production environment, and remove unnecessary plug-ins.

Make sure to start webpack.DefinePlugin and webpack.optimize.UglifyJsPlugin in the production environment.

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
  }
  })   
]

Split business code and third-party libraries and public modules

Due to the high frequency of business code changes in the project, Code changes in third-party libraries are relatively infrequent. If the business code and the third library are packaged into the same chunk, at each build, even if the business code only changes one line, even if the code of the third-party library does not change, the hash of the entire chunk will be different from the last time. . This is not the result we want. What we want is that if the code of the third-party library does not change, then we must ensure that the corresponding hash does not change when building, so that we can use the browser cache to better improve page loading performance and shorten page loading time.

因此可以将第三库的代码单独拆分成 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多入口文件页面打包详解

The above is the detailed content of Detailed explanation of React and Webpack construction and packaging optimization examples. For more information, please follow other related articles on the PHP Chinese website!