>

配备最棒施行,塑造打包优化

- 编辑:至尊游戏网站 -

配备最棒施行,塑造打包优化

Webpack 4 配置最棒实施

2018/06/22 · JavaScript · webpack

初藳出处: Zindex   

Webpack 4 公布已经有生龙活虎段时间了。Webpack 的版本号已经到来了 4.12.x。但因为 Webpack 官方还并未有造成搬迁指南,在文书档案层面上还兼具欠缺,抢先61%人对升级 Webpack 照旧没头没脑。

而是 Webpack 的费用公司曾经写了有个别零星的作品,官方网址络也许有了新版配置的文书档案。社区中一些开辟者也早已成功试水,进级到了 Webpack 4,况兼总结成了博客。所以作者也总算去询问了 Webpack 4 的具体情状。以下便是自己对搬迁到 Webpack 4 的局部经验。

正文的首要在:

  • Webpack 4 在安插上带来了哪些方便?要搬迁须求改进配置文件的什么内容?
  • 事先的 Webpack 配置最棒执行在 Webpack 4 这么些版本,还适用吗?

浅谈React + Webpack 营造打包优化,reactwebpack

正文介绍了React + Webpack 营造打包优化,分享给我们,具体如下:

应用 babel-react-optimize 对 React 代码举办优化

自己批评没有运用的库,去除 import 援用

按需打包所用的类库,比方 lodash 、 echart 等

lodash 能够应用babel-plugin-lodash 实行优化。

亟待注意的是

在 babel-react-optimize 中采纳了 babel-plugin-transform-react-remove-prop-types 那么些插件。寻常意况下,倘让你在代码中从不援用到构件的 PropTypes ,则一心没难点。要是你的组件用到了,那么使用该插件或者会变成难题。

具体见:

Webpack 创设打包优化

Webpack 构建打包存在的标题关键聚焦于上边五个方面:

  1. Webpack 构建速度慢
  2. Webpack 打包后的公文娱体育积过大

Webpack 构建速度慢

能够运用 Webpack.DDLPlugin , HappyPack 来增加营造速度。具体参见小铭在 DMP DDLPlugin 的文档。原来的小说如下:

Webpack.DLLPlugin

累计三个 webpack.dll.config.js
主倘使用到三个 DllPlugin 插件,把某个第三方的财富独立包装,同有的时候间停放四个manifest.json 配置文件中,

如此那般在组件中立异后,就不会再也 build 那一个第三方的能源,

  1. 再便是独立铺排 dll/vendors.js 文件,提须要 webpack.dll.config.js
  2. 修改 package.json

在 scripts 中添加: "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')
})

修改 html

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

注意,供给在 htmlWebpackPlugin 插件中配置 NODE_ENV 参数

Happypack

因而十二线程,缓存等方法进步 rebuild 效用

在 webpack.dev.config.js 中针对区别的能源创立五个 HappyPack, 比方 js 1 个,less 1 个,并设置好 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'],
})

在 module.rules 中配置 use 为 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 打包后的文件体积大小

先是须求对大家全体 bundle 举行分析,由什么东西组成及各组成都部队分所占大小。

那边推荐 webpack-bundle-analyzer 。安装后在 webpack.dev.config.js 中足够插件就能够,就会在每回运转后活动在网站展开解析结果,如下图

plugins.push( new BundleAnalyzerPlugin());

图片 1

除却,还是能将打包进程输出成json文件

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

接下来到下边那五个网址开展剖释

  1. webpack/analyse
  2. Webpack Chart

通过上边的图形解析可以清楚得看看,整个 bundle.js 的组成都部队分及相应的深浅。

消除 bundle.js 体积过大的解决思路如下:

  1. 生育景况启用压缩等插件,去除不需要插件
  2. 拆分业务代码与第三方库及集人体模型块
  3. webpack 开启 gzip 压缩
  4. 按需加载

生儿育女条件启用压缩等插件,去除无需插件

保证在生养境况运行 webpack.DefinePlugin 和 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
  }
  })   
]

拆分业务代码与第三方库及公共模块

由于项指标事情代码改动频率超高,而第三方库的代码变化则相对未有那么频率。假如将职业代码和第三库打包到同一个chunk 的话,在每一遍创设的时候,哪怕业务代码只改了风华正茂行,即便第三方库的代码未有发生变化,会促成整个 chunk 的 hash 跟上叁遍差别。那不是大家想要的结果。我们想要的是,假若第三方库的代码未有成形,那在营造的时候也要保险相应的 hash 未有爆发变化,进而能接纳浏览器缓存,越来越好的滋长页面加载质量和浓缩页面加载时间。

为此能够将第三库的代码单独拆分成 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,但里边未有模块。

愈来愈多关于 CommonChunkPlugin 可以查阅 官方文书档案

拆分公共能源

同 下面的拆分第三方库肖似,拆分公共能源得以将公用的模块单独打出叁个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
})

以上正是本文的全部内容,希望对我们的上学抱有助于,也愿意大家多多指教帮客之家。

+ Webpack 营造打包优化,reactwebpack 本文介绍了React + Webpack 营造打包优化,分享给我们,具体如下: 使用 babel-react-optimize 对 React 代...

Webpack 4 事先的 Webpack 最棒实行

这里以 Vue 官方的 Webpack 模板 vuejs-templates/webpack 为例,说说 Webpack 4 在此之前,社区里相比成熟的 Webpack 配置文件是如何协会的。

差别开拓和生育意况

大意的目录结构是那样的:

+ build + config + src

1
2
3
+ build
+ config
+ src

在 build 目录下有四个 webpack 的布局。分别是:

  • webpack.base.conf.js
  • webpack.dev.conf.js
  • webpack.prod.conf.js
  • webpack.test.conf.js

那分别对应开垦、生产和测量试验境况的安排。当中 webpack.base.conf.js 是部分公共的布署项。大家应用 webpack-merge 把那么些公共配置项和条件特定的安顿项 merge 起来,成为叁个整机的安插项。比方 webpack.dev.conf.js 中:

'use strict' const merge = require('webpack-merge') const baseWebpackConfig = require('./webpack.base.conf') const devWebpackConfig = merge(baseWebpackConfig, { ... })

1
2
3
4
5
6
7
'use strict'
const merge = require('webpack-merge')
const baseWebpackConfig = require('./webpack.base.conf')
 
const devWebpackConfig = merge(baseWebpackConfig, {
   ...
})

那多个情状不止有部分配备分化,更要紧的是,每一个配置中用 webpack.DefinePlugin 向代码注入了 NODE_ENV 这一个情形变量。

本条变量在差别条件下有分歧的值,比如 dev 遭遇下就是development。那一个境况变量的值是在 config 文件夹下的配置文件中定义的。Webpack 首先从布局文件中读取这么些值,然后注入。例如那样:

build/webpack.dev.js

plugins: [ new webpack.DefinePlugin({ 'process.env': require('../config/dev.env.js') }), ]

1
2
3
4
5
plugins: [
  new webpack.DefinePlugin({
    'process.env': require('../config/dev.env.js')
  }),
]

config/dev.env.js

module.exports ={ NODE_ENV: '"development"' }

1
2
3
module.exports ={
  NODE_ENV: '"development"'
}

关于分化条件下情状变量具体的值,比方开拓境遇是 development,坐褥情状是 production,其实是大户人家相沿成习的。

框架、库的审核人,可能是咱们的事体代码里,都会有一点依照情形做判定,推行不意气风发逻辑的代码,比方那样:

if (process.env.NODE_ENV !== 'production') { console.warn("error!") }

1
2
3
if (process.env.NODE_ENV !== 'production') {
  console.warn("error!")
}

那一个代码会在代码压缩的时候被预施行贰回,然后倘若基准表明式的值是 true,那那个 true 分支里的剧情就被移除了。那是生龙活虎种编写翻译时的死代码优化。这种区别分裂的条件,并给碰着变量设置差别的值的实施,让我们打开了编写翻译时按遇到对代码实行针对性优化的或是。

Code Splitting && Long-term caching

Code Splitting 日常须求做这么些专门的学问:

  • 为 Vendor 单独包装(Vendor 指第三方的库或许国有的底蕴构件,因为 Vendor 的更换少之甚少,单独打包利于缓存卡塔尔国
  • 为 Manifest (Webpack 的 Runtime 代码卡塔 尔(英语:State of Qatar)单独包装
  • 为差别入口的公物事务代码打包(同理,也是为着缓存和加载速度卡塔 尔(英语:State of Qatar)
  • 为异步加载的代码打多少个公家的包

Code Splitting 平常是由此安顿 CommonsChunkPlugin 来产生的。一个非凡的布署如下,分别为 vendor、manifest 和 vendor-async 配置了 CommonsChunkPlugin。

new webpack.optimize.CommonsChunkPlugin({ name: 'vendor', minChunks (module) { return ( module.resource && /.js$/.test(module.resource) && module.resource.indexOf( path.join(__dirname, '../node_modules') ) === 0 ) } }), new webpack.optimize.CommonsChunkPlugin({ name: 'manifest', minChunks: Infinity }), new webpack.optimize.CommonsChunkPlugin({ name: 'app', async: 'vendor-async', children: true, minChunks: 3 }),

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
    new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks (module) {
        return (
          module.resource &&
          /.js$/.test(module.resource) &&
          module.resource.indexOf(
            path.join(__dirname, '../node_modules')
          ) === 0
        )
      }
    }),
 
    new webpack.optimize.CommonsChunkPlugin({
      name: 'manifest',
      minChunks: Infinity
    }),
 
    new webpack.optimize.CommonsChunkPlugin({
      name: 'app',
      async: 'vendor-async',
      children: true,
      minChunks: 3
    }),

CommonsChunkPlugin 的性子就是安插相比较难懂,我们的布局往往是复制过来的,那么些代码基本上成了模版代码(boilerplate卡塔 尔(阿拉伯语:قطر‎。假使Code Splitting 的渴求轻易倒好,假若有比较奇特的须要,比方把差别入口的 vendor 打分裂的包,那就很难布署了。简单来讲配置 Code Splitting 是三个比较难熬的作业。

而 Long-term caching 计策是那样的:给静态文件叁个十分长的缓存过期光阴,例如一年。然后在给文件名里加上三个hash,每一趟构建时,当文件内容更改时,文件名中的 hash 也会转移。浏览器在依附文件名作为文件的标记,所以当 hash 改换时,浏览器就能够再一次加载那个文件。

Webpack 的 Output 选项中得以配备文件名的 hash,比方这样:

output: { path: config.build.assetsRoot, filename: utils.assetsPath('js/[name].[chunkhash].js'), chunkFilename: utils.assetsPath('js/[id].[chunkhash].js') },

1
2
3
4
5
output: {
  path: config.build.assetsRoot,
  filename: utils.assetsPath('js/[name].[chunkhash].js'),
  chunkFilename: utils.assetsPath('js/[id].[chunkhash].js')
},

Webpack 4 下的精品实施

Webpack 4 的变与不改变

Webpack 4 这几个本子的 API 有局地 breaking change,但不意味说那些版本就发出了倾覆的变型。其实变化的点独有多少个。并且即使你留神打听了这个变迁,你早晚上的集会歌唱。

搬迁到 Webpack 4 也只须要检查一下 checklist,看看那个点是还是不是都蒙蔽到了,就能够了。

支付和生育环境的分裂

Webpack 4 引入了 mode 这么些选项。那几个选项的值可以是 development 或然 production。

安装了 mode 之后会把 process.env.NODE_ENV 也设置为 development 或者production。然后在 production 情势下,会私下认可开启 UglifyJsPlugin 等等一批插件。

Webpack 4 扶助零布局利用,能够从命令行钦命 entry 的职位,假设不点名,便是 src/index.js。mode 参数也能够从命令行参数字传送入。那样局部常用的生育情形打包优化都足以向来启用。

咱俩须要潜心,Webpack 4 的零配置是有限度的,若是要加多自个儿想加的插件,或然要加三个entry,如故供给二个铺排文件。

即使如此如此,Webpack 4 在各种方面都做了大力,努力让零配置能够做的事务越来越多。这种内置优化的措施使得大家在品种运行的时候,能够把第黄金年代精力放在工作支付上,等后期业务变复杂过后,才要求关心配置文件的编排。

在 Webpack 4 推出 mode 那么些选项以前,如若想要为区别的开销条件构建不一样的创设选项,大家只能通过创立多个Webpack 配置且分别设置差别的景况变量值这种方法。那也是社区里的极品执行。

Webpack 4 推出的 mode 选项,其实是生龙活虎种对社区中特级实践的收纳。这种思路作者是很同情的。开源项目来自于社区,在社区中成长,从社区中吸收接纳养分,然后回报社区,那是三个良性循环。这两天作者在众多前端项目中都见到了相通的大势。接下来要讲的此外多少个Webpack 4 的表征也是和社区的反馈离不开的。

那正是说上文中介绍的运用三个 Webpack 配置,以致手动处境变量注入的方法,是或不是在 Webpack 4 下就不适用了啊?其实不然。在Webpack 4 下,对于一个纯正的花色,大家依然必要八个例外的安插文件。假诺大家对为测验情况的打包做一些新鲜处理,大家还索要在极其配置文件里用 webpack.DefinePlugin 手动注入 NODE_ENV 的值(比如 test)。

Webpack 4 下即使要求贰个 test 际遇,那 test 情形的 mode 也是 development。因为 mode 唯有付出和生育二种,测验遇到应该是归属开垦阶段。

其三方库 build 的取舍

在 Webpack 3 一代,大家须要在生育意况的的 Webpack 配置里给第三方库设置 alias,把那些库的路线设置为 production build 文件的门径。以此来引入临蓐版本的注重。

诸如那样:

resolve: { extensions: [".js", ".vue", ".json"], alias: { vue$: "vue/dist/vue.runtime.min.js" } },

1
2
3
4
5
6
resolve: {
  extensions: [".js", ".vue", ".json"],
  alias: {
    vue$: "vue/dist/vue.runtime.min.js"
  }
},

在 Webpack 4 引入了 mode 之后,对于有个别注重,大家得以不要配置 alias,比方 React。React 的入口文件是如此的:

'use strict'; if (process.env.NODE_ENV === 'production') { module.exports = require('./cjs/react.production.min.js'); } else { module.exports = require('./cjs/react.development.js'); }

1
2
3
4
5
6
7
'use strict';
 
if (process.env.NODE_ENV === 'production') {
  module.exports = require('./cjs/react.production.min.js');
} else {
  module.exports = require('./cjs/react.development.js');
}

那般就兑现了 0 配置活动选用临盆 build。

但多数的第三库并未做那个进口的情状决断。所以这种状态下大家仍旧供给手动配置 alias。

Code Splitting

Webpack 4 下还会有一个大更动,就是废除了 CommonsChunkPlugin,引进了 optimization.splitChunks 这一个选项。

optimization.splitChunks 暗许是不用安装的。假若 mode 是 production,那Webpack 4 就能够展开 Code Splitting。

暗中同意 Webpack 4 只会对按需加载的代码做分割。如若大家供给安顿开首加载的代码也加入到代码分割中,能够设置 splitChunks.chunks 为 ‘all’。

Webpack 4 的 Code Splitting 最大的特征正是布置轻松(0配置起步卡塔尔国,和基于内置法规自动拆分。内置的代码切分的平整是如此的:

  • 新 bundle 被四个及以上模块援引,恐怕来自 node_modules
  • 新 bundle 大于 30kb (压缩在此以前卡塔尔
  • 异步加载并发加载的 bundle 数不能够超出 5 个
  • 开头加载的 bundle 数不可能超越 3 个

简短的说,Webpack 会把代码中的公共模块自动抽取来,造成叁个包,前提是这一个包大于 30kb,不然Webpack 是不会挤出公共代码的,因为扩张二遍呼吁的本金是不可能忽略的。

具体的业务场景下,具体的拆分逻辑,能够看 SplitChunksPlugin 的文档以及 webpack 4: Code Splitting, chunk graph and the splitChunks optimization 那篇博客。这两篇文章基本陈列了具有很大可能率现身的图景。

借使是管见所及的施用,Webpack 4 内置的法规就丰裕了。

假如是极度的供给,Webpack 4 的 optimization.splitChunks API也得以满足。

splitChunks 有三个参数叫 cacheGroups,这些参数相似事先的 CommonChunks 实例。cacheGroups 里每一个对象便是三个顾客定义的 chunk。

事先大家讲到,Webpack 4 内置有生龙活虎套代码分割的准绳,那客户也能够自定义 cacheGroups,约等于自定义 chunk。这一个 module 应该被抽到哪些 chunk 呢?这是由 cacheGroups 的收取范围调节的。每一个 cacheGroups 都能够定义自身取出模块的界定,也等于怎么文件中的公共代码会收取到谐和那一个chunk 中。区别的 cacheGroups 之间的模块范围假若有和弄,我们能够用 priority 属性调控优先级。Webpack 4 暗中同意的抽出的事先级是最低的,所以模块会预先被收取到客户的自定义 chunk 中。

splitChunksPlugin 提供了两种调节 chunk 收取模块范围的措施。生机勃勃种是 test 属性。这几个特性能够流传字符串、正则大概函数,全数的 module 都会去相称test 传入的尺度,如若基准切合,就被归入这些 chunk 的预备模块范围。借使大家传入的准则是字符串或然正则,那相配的流水生产线是那般的:首先相配module 的不二秘籍,然后相配 module 在此之前所在 chunk 的 name。

举例大家想把全数 node_modules 中引进的模块打包成一个模块:

vendors1: { test: /[/]node_modules[/]/, name: 'vendor', chunks: 'all', }

1
2
3
4
5
  vendors1: {
    test: /[/]node_modules[/]/,
    name: 'vendor',
    chunks: 'all',
  }

因为从 node_modules 中加载的信任性路线中都含有 node_modules,所以那么些正则会合营全部从 node_modules 中加载的依附。

test 属性能够以 module 为单位调控 chunk 的收取范围,是豆蔻年华种细粒度相当小的点子。splitChunksPlugin 的第三种调控抽取模块范围的主意就是 chunks 属性。chunks 能够是字符串,比如 ‘all’|’async’|’initial’,分别代表了整整 chunk,按需加载的 chunk 以致最早加载的 chunk。chunks 也得以是三个函数,在这里个函数里大家能够获得chunk.name。那给了作者们通过入口来划分代码的力量。那是少年老成种细粒度超级大的方法,以 chunk 为单位。

譬如,比如大家有 a, b, c 多个入口。大家希望 a,b 的公共代码单独打包为 common。也正是说 c 的代码不参与集体代码的分割。

咱俩得以定义叁个 cacheGroups,然后设置 chunks 属性为一个函数,那一个函数肩负过滤这几个 cacheGroups 富含的 chunk 是何许。示例代码如下:

optimization: { splitChunks: { cacheGroups: { common: { chunks(chunk) { return chunk.name !== 'c'; }, name: 'common', minChunks: 2, }, }, }, },

1
2
3
4
5
6
7
8
9
10
11
12
13
  optimization: {
    splitChunks: {
      cacheGroups: {
        common: {
          chunks(chunk) {
            return chunk.name !== 'c';
          },
          name: 'common',
          minChunks: 2,
        },
      },
    },
  },

地点配置的情致正是:我们想把 a,b 入口中的公共代码单独打包为三个名称叫common 的 chunk。使用 chunk.name,大家能够轻便的成功那几个必要。

在上头的意况中,大家明白 chunks 属性能够用来按入口切分几组公共代码。未来我们来看叁个微微复杂一些的景况:对不一致分组入口中引进的 node_modules 中的注重进行分组。

举个例子说大家有 a, b, c, d 多少个入口。大家意在 a,b 的依赖打包为 vendor1,c, d 的正视性打包为 vendor2。

其风流倜傥须要供给大家对进口和模块都做过滤,所以大家供给利用 test 属性那一个细粒度相当的小的法子。大家的笔触就是,写几个 cacheGroup,二个cacheGroup 的决断规范是:要是 module 在 a 也许 b chunk 被引进,而且module 的路子蕴含 node_modules,那那几个 module 就相应被打包到 vendors第11中学。 vendors2 同理。

vendors1: { test: module => { for (const chunk of module.chunksIterable) { if (chunk.name && /(a|b)/.test(chunk.name)) { if (module.nameForCondition() && /[/]node_modules[/]/.test(module.nameForCondition())) { return true; } } } return false; }, minChunks: 2, name: 'vendors1', chunks: 'all', }, vendors2: { test: module => { for (const chunk of module.chunksIterable) { if (chunk.name && /(c|d)/.test(chunk.name)) { if (module.nameForCondition() && /[/]node_modules[/]/.test(module.nameForCondition())) { return true; } } } return false; }, minChunks: 2, name: 'vendors2', chunks: 'all', }, };

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  vendors1: {
    test: module => {
      for (const chunk of module.chunksIterable) {
            if (chunk.name && /(a|b)/.test(chunk.name)) {
                if (module.nameForCondition() && /[/]node_modules[/]/.test(module.nameForCondition())) {
                 return true;
             }
            }
       }
      return false;
    },
    minChunks: 2,
    name: 'vendors1',
    chunks: 'all',
  },
  vendors2: {
    test: module => {
      for (const chunk of module.chunksIterable) {
            if (chunk.name && /(c|d)/.test(chunk.name)) {
                if (module.nameForCondition() && /[/]node_modules[/]/.test(module.nameForCondition())) {
                 return true;
             }
            }
       }
      return false;
    },
    minChunks: 2,
    name: 'vendors2',
    chunks: 'all',
  },
};

Long-term caching

Long-term caching 这里,基本的操作和 Webpack 3 是如出一辙的。然而 Webpack 3 的 Long-term caching 在操作的时候,有个小难题,那么些主题素材是关于 chunk 内容和 hash 变化不相近的:

在公私代码 Vendor 内容不改变的意况下,增多 entry,只怕 external 注重,恐怕异步模块的时候,Vendor 的 hash 会改变

前边 Webpack 官方的专栏里面有风姿浪漫篇文章讲那个主题材料:Predictable long term caching with Webpack。给出了四个缓慢解决方案。

本条方案的宗旨正是,Webpack 内部维护了三个自增的 id,各个 chunk 都有贰个id。所以当增添 entry 可能其它品类 chunk 的时候,id 就能够转换,招致内容还没转换的 chunk 的 id 也时有发生了变通。

对此我们的答问方案是,使用 webpack.NamedChunksPlugin 把 chunk id 变为贰个字符串标志符,这一个字符包平常便是模块的相对路线。这样模块的 chunk id 就能够稳固下来。

图片 2

这里的 vendors1 就是 chunk id

HashedModuleIdsPlugin 的效能和 NamedChunksPlugin 是同等的,只不过 HashedModuleIdsPlugin 把依照模块相对路线生成的 hash 作为 chunk id,那样 chunk id 会更加短。由此在生养中更推荐用 HashedModuleIdsPlugin。

那篇作品说还讲到,webpack.NamedChunksPlugin 只好对平时的 Webpack 模块起功用,异步模块,external 模块是不会起效果的。

异步模块能够在 import 的时候增加 chunkName 的注明,举例这样:import(/ webpackChunkName: “lodash” / ‘lodash’).then() 那样就有 Name 了

所以大家供给再使用一个插件:name-all-modules-plugin

本条插件中用到一些老的 API,Webpack 4 会发出警示,那么些 pr 有新的版本,然则作者不肯定会 merge。大家选取的时候能够一向 copy 那几个插件的代码到大家的 Webpack 配置内部。

做了那几个工作今后,大家的 Vendor 的 ChunkId 就再也不会爆发不应当发生的更换了。

总结

Webpack 4 的更换首假使对社区中特级实行的选用。Webpack 4 透过新的 API 大大晋级了 Code Splitting 的心得。但 Long-term caching 中 Vendor hash 的难点或许未有解决,必要手动配置。本文首要介绍的正是 Webpack 配置最棒试行在 Webpack 3.x 和 4.x 背景下的争论。希望对读者的 Webpack 4 项目标配置文件组织有所支持。

另外,推荐 SURVIVEJS – WEBPACK 那些在线教程。那个课程计算了 Webpack 在实质上开拓中的践行,何况把资料更新到了新星的 Webpack 4。

1 赞 4 收藏 评论

图片 3

本文由设计建站发布,转载请注明来源:配备最棒施行,塑造打包优化