React와 Webpack 구성 및 패키징 최적화 예시에 대한 자세한 설명

이 글은 주로 React + Webpack 구축과 패키징 최적화에 대한 간략한 논의를 소개합니다. 편집자는 꽤 좋다고 생각해서 지금 공유하고 참고용으로 제공하겠습니다. 편집자를 따라가서 모두에게 도움이 되기를 바랍니다.

babel-react-optimize를 사용하여 React 코드 최적화

사용하지 않는 라이브러리를 확인하고 가져오기 참조를 제거하세요

lodash, echart 등과 같이 필요에 따라 사용되는 라이브러리를 패키지합니다.

lodash는 babel-plugin -lodash를 사용할 수 있습니다. 최적화를 위해.

babel-react-optimize에서 babel-plugin-transform-react-remove-prop-types 플러그인을 사용한다는 점에 유의해야 합니다. 일반적으로 코드에서 구성 요소의 PropType을 참조하지 않아도 전혀 문제가 없습니다. 이 플러그인을 사용하면 구성 요소에서 이를 사용하는 경우 문제가 발생할 수 있습니다.

자세한 내용은 다음을 참조하세요.

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

Webpack 빌드 및 패키지 최적화

Webpack 빌드 및 패키지 존재 문제는 주로 다음 두 가지 측면에 중점을 둡니다.

1. Webpack 빌드 속도가 느림

2. Webpack의 패키지 파일 크기가 너무 큼

Webpack 빌드 속도가 느림

을 사용할 수 있습니다. Webpack.DDLPlugin 및 HappyPack 빌드 속도가 향상됩니다. 자세한 내용은 DMP DDLPlugin에 대한 Xiaoming의 문서를 참조하세요. 원본 텍스트는 다음과 같습니다.

Webpack.DLLPlugin

webpack.dll.config.js 추가
주로 DllPlugin 플러그인을 사용하여 일부 타사 리소스를 독립적으로 패키지하고 이를 Manifest.json 구성 파일에 넣습니다.

이러한 방식으로 구성 요소를 업데이트한 후에는 이러한 타사 리소스가 다시 빌드되지 않습니다.

1. 동시에 dll/vendors.js 파일이 독립적으로 구성되어 webpack.dll.config에 제공됩니다. .js

2. package.json

   수정

추가: "dll": "webpack --config webpack.dll.config.js --progress --colors ", 스크립트에.

npm run dll을 실행하면 dll 디렉터리에 Vendor-manifest.json과 Vendor.dll.js 두 파일이 생성됩니다.

webpack.dev.config.js 파일을 구성하고 DllReferencePlugin 플러그인을 추가한 후 지정합니다. Vendor-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>
<% } %>

htmlWebpackPlugin

Happypack

Improve에서 NODE_ENV 매개변수를 구성해야 합니다. 멀티를 통해 효율성을 재구축하세요. 스레딩, 캐싱 등 https://github.com/amireh/happypack

webpack.dev.config.js에서 js 1개, 1개 이하 등 다양한 리소스에 대해 여러 개의 HappyPack을 만들고 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'],
})

모듈에서 happypack/loader로 사용을 구성하고 id를 설정하세요

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

Webpack 패키징 후 파일 크기를 줄이세요

먼저 전체 번들을 분석해야 합니다. 각 구성 요소의 크기와 크기.

여기에서는 Webpack-bundle-analyzer를 권장합니다. 설치 후 webpack.dev.config.js에 플러그인을 추가하기만 하면 아래와 같이 시작할 때마다 분석 결과가 자동으로 웹사이트에 열립니다

plugins.push( new BundleAnalyzerPlugin());

또한 package 프로세스는 json 파일로 출력됩니다

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

그 다음 분석을 위해 다음 두 사이트로 이동하세요

1. webpack/analyse

2. Webpack Chart

위 차트를 보면 명확하게 알 수 있습니다. 전체 번들 .js 구성 요소와 해당 크기를 분석합니다.

bundle.js 크기가 과도해지는 문제에 대한 해결책은 다음과 같습니다.

1. 프로덕션 환경에서 압축 및 기타 플러그인을 활성화하고 불필요한 플러그인을 제거합니다.

2. 비즈니스 코드와 타사 분할 라이브러리 및 공용 모듈

3. webpack gzip 압축 활성화

4. 필요에 따라 로드

프로덕션 환경에서 압축 및 기타 플러그인을 활성화하고, 불필요한 플러그인을 제거합니다.

webpack을 시작해야 합니다.플러그인 정의 및 프로덕션 환경의 webpack.optimize.UglifyJsPlugin.

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

비즈니스 코드를 타사 라이브러리 및 공용 모듈로 분할

프로젝트의 비즈니스 코드는 매우 자주 변경되므로 타사 라이브러리의 코드는 상대적으로 덜 자주 변경됩니다. 비즈니스 코드와 세 번째 라이브러리가 동일한 청크로 패키징되면 각 빌드에서 비즈니스 코드가 한 줄만 변경되더라도 타사 라이브러리의 코드가 변경되지 않더라도 전체 청크의 해시가 지난번과 달라. 이는 우리가 원하는 결과가 아닙니다. 우리가 원하는 것은 타사 라이브러리의 코드가 변경되지 않으면 빌드 시 해당 해시가 변경되지 않도록 해야 브라우저 캐시를 사용하여 페이지 로딩 성능을 향상시키고 페이지 로딩을 단축할 수 있다는 것입니다. 시간.

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

위 내용은 React와 Webpack 구성 및 패키징 최적화 예시에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!