New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

没有了CommonsChunkPlugin,咱拿什么来分包(译) #15

Open
yesvods opened this Issue Feb 28, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@yesvods
Owner

yesvods commented Feb 28, 2018

原文:RIP CommonsChunkPlugin

webpack 4 移除 CommonsChunkPlugin,取而代之的是两个新的配置项(optimization.splitChunks 和 optimization.runtimeChunk),下面介绍一下用法和机制。

默认方式

webpack模式模式现在已经做了一些通用性优化,适用于多数使用者。

需要注意的是:默认模式只影响按需(on-demand)加载的代码块(chunk),因为改变初始代码块会影响声明在HTML的script标签。如果可以处理好这些(比如,从打包状态里面读取并动态生成script标签到HTML),你可以通过设置optimization.splitChunks.chunks: "all",应用这些优化模式到初始代码块(initial chunk)。

webpack根据下述条件自动进行代码块分割:

  • 新代码块可以被共享引用,OR这些模块都是来自node_modules文件夹里面
  • 新代码块大于30kb(min+gziped之前的体积)
  • 按需加载的代码块,最大数量应该小于或者等于5
  • 初始加载的代码块,最大数量应该小于或等于3

为了满足后面两个条件,webpack有可能受限于包的最大数量值,生成的代码体积往上增加。

我们来看一下一些例子:

Example 1

// entry.js
import("./a");
// a.js
import "react-dom";
// ...

结果:webpack会创建一个包含react-dom的分离代码块。当import调用时候,这个代码块就会与./a代码被并行加载。

为什么会这样打包:

  • 条件1:这个代码块是从node_modules来的
  • 条件2:react-dom大于30kb
  • 条件3:按需请求的数量是2(小于5)
  • 条件4:不会影响初始代码请求数量

这样打包有什么好处呢?

对比起你的应用代码,react-dom可能不会经常变动。通过将它分割至另外一个代码块,这个代码块可以被独立缓存起来(假设你在用的是长期缓存策略:chunkhash,records,Cache-Control)

Example 2

// entry.js
import("./a");
import("./b");
// a.js
import "./helpers"; // helpers is 40kb in size
// ...
// b.js
import "./helpers";
import "./more-helpers"; // more-helpers is also 40kb in size
// ...

结果:webpack会创建一个包含./helpers的独立代码块,其他模块会依赖于它。在import被调用时候,这个代码块会跟原始的代码并行加载(译注:它会跟a.jsb.js并行加载)。

为什么会这样打包:

  • 条件1:这个代码块会被两个动态导入(import)调用依赖(指的是a.jsb.js
  • 条件2:helpers体积大于30kb
  • 条件3:按需请求的数量是2(小于5)
  • 条件4:不会影响初始代码请求数量

这样打包有什么好处呢?

helpers代码放在每一个依赖的块里,可能就意味着,用户重复会下载它两次。通过用一个独立的代码块分割,它只需要被下载一次。实际上,这只是一种折衷方案,因为我们为此需要付出额外的一次请求的代价。这就是为什么默认webpack将最小代码块分割体积设置成30kb(译注:太小体积的代码块被分割,可能还会因为额外的请求,拖慢加载性能)。

通过optimizations.splitChunks.chunks: "all",上面的策略也可以应用到初始代码块上(inital chunks)。代码代码块也会被多个入口共享&按需加载(译注:以往我们使用CommonsChunkPlugin最通常的目的)。

配置

如果想要更深入控制这个按需分块的功能,这里提供很多选项来满足你的需求。

Disclaimer:不要在没有实践测量的情况下,尝试手动优化这些参数。默认模式是经过千挑万选的,可以用于满足最佳web性能的策略。

缓存组(Cache Group)

这项优化可以用于将模块分配到对应的Cache group

默认模式会将所有来自node_modules的模块分配到一个叫vendors的缓存组;所有重复引用至少两次的代码,会被分配到default的缓存组。

一个模块可以被分配到多个缓存组,优化策略会将模块分配至跟高优先级别(priority)的缓存组,或者会分配至可以形成更大体积代码块的组里。

Conditions

在满足下述所有条件时,那些从相同代码块和缓存组来的模块,会形成一个新的代码块(译注:比如,在满足条件下,一个vendoer可能会被分割成两个,以充分利用并行请求性能)。

有四个选项可以用于配置这些条件:

  • minSize(默认是30000):形成一个新代码块最小的体积
  • minChunks(默认是1):在分割之前,这个代码块最小应该被引用的次数(译注:保证代码块复用性,默认配置的策略是不需要多次引用也可以被分割)
  • maxInitialRequests(默认是3):一个入口最大的并行请求数
  • maxAsyncRequests(默认是5):按需加载时候最大的并行请求数。

Naming

要控制代码块的命名,可以用name参数来配置。

注意:当不同分割代码块被赋予相同名称时候,他们会被合并在一起。这个可以用于在:比如将那些多个入口/分割点的共享模块(vendor)合并在一起,不过不推荐这样做。这可能会导致加载额外的代码。

如果赋予一个神奇的值true,webpack会基于代码块和缓存组的key自动选择一个名称。除此之外,可以使用字符串或者函数作为参数值。

当一个名称匹配到相应的入口名称,这个入口会被移除。

Select chunks

通过chunks选项,可以配置控制webpack选择哪些代码块用于分割(译注:其他类型代码块按默认方式打包)。有3个可选的值:initialasyncall。webpack将会只对配置所对应的代码块应用这些策略。

reuseExistingChunk选项允许复用已经存在的代码块,而不是新建一个新的,需要在精确匹配到对应模块时候才会生效。

这个选项可以在每个缓存组(Cache Group)里面做配置。

Select modules

test选项用于控制哪些模块被这个缓存组匹配到。原封不动传递出去的话,它默认会选择所有的模块。可以传递的值类型:RegExpStringFunction

通过这个选项,可以通过绝对资源路径(absolute modules resource path)或者代码块名称(chunk names)来匹配对应模块。当一个代码块名称(chunk name)被匹配到,这个代码块的所有模块都会被选中。

配置缓存组(Configurate cache group)

这是默认的配置:

splitChunks: {
	chunks: "async",
	minSize: 30000,
	minChunks: 1,
	maxAsyncRequests: 5,
	maxInitialRequests: 3,
	name: true,
	cacheGroups: {
		default: {
			minChunks: 2,
			priority: -20,
			reuseExistingChunk: true,
		},
		vendors: {
			test: /[\\/]node_modules[\\/]/,
			priority: -10
		}
	}
}

默认来说,缓存组会继承splitChunks的配置,但是testpriortyreuseExistingChunk只能用于配置缓存组。

cacheGroups是一个对象,按上述介绍的键值对方式来配置即可,值代表对应的选项:

除此之外,所有上面列出的选择都是可以用在缓存组里的:chunks, minSize, minChunks, maxAsyncRequests, maxInitialRequests, name

可以通过optimization.splitChunks.cacheGroups.default: false禁用default缓存组。

default缓存组的优先级(priotity)是负数,因此所有自定义缓存组都可以有比它更高优先级(译注:更高优先级的缓存组可以优先打包所选择的模块)(默认自定义缓存组优先级为0)

可以用一些例子来说明:

Example 1

splitChunks: {
	cacheGroups: {
		commons: {
			name: "commons",
			chunks: "initial",
			minChunks: 2
		}
	}
}

这会创建一个commons代码块,这个代码块包含所有被其他入口(entrypoints)共享的代码。

注意:这可能会导致下载额外的代码。

Example 2

splitChunks: {
	cacheGroups: {
		commons: {
			test: /[\\/]node_modules[\\/]/,
			name: "vendors",
			chunks: "all"
		}
	}
}

这会创建一个名为vendors的代码块,它会包含整个应用所有来自node_modules的代码。

注意:这可能会导致下载额外的代码。

optimization.runtimeChunk

通过optimization.runtimeChunk: true选项,webpack会添加一个只包含运行时(runtime)额外代码块到每一个入口。(译注:这个需要看场景使用,会导致每个入口都加载多一份运行时代码)

@yesvods yesvods added the webpack label Feb 28, 2018

@yangfch3

This comment has been minimized.

yangfch3 commented May 19, 2018

现阶段阅读过的最流畅准确的翻译

@x-shadow-x

This comment has been minimized.

x-shadow-x commented Nov 28, 2018

你好,想问下,example2中第一个条件“这个代码块会被两个导入(import)调用依赖(指的是a.js和b.js)”这里说的导入是不是特指help会被两个动态导入的模块依赖?我测试的时候发现如果entry.js导入a.js和b.js的写法不是动态导入而是改成import a from './a.js和import b from './b.js'或者require('./a.js')和require('./b.js')的话,helpers就不会单独打出一个包来~所以example2的第一个条件是不是可以说成“这个代码块会被两个动态的导入(import)的模块调用依赖(指的是a.js和b.js)”~求解答

@yesvods

This comment has been minimized.

Owner

yesvods commented Nov 29, 2018

是的,这里的导入意思指的就是动态导入。已修改,感谢指正。 @x-shadow-x

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment