您的位置:时时app平台注册网站 > web前端 > Webpack 4 配置最棒实行

Webpack 4 配置最棒实行

2019-10-14 22:41

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 就可以牢固下来。

图片 1

这里的 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 就再也不会发生不应该产生的变动了。

  1. 使用 chunkhash 而不用 hash
  2. 独自拆分 webpack 自个儿代码

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 就应有被打包到 vendors1中。 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',
  },
};

保证在生育情状运维 webpack.DefinePlugin 和 webpack.optimize.UglifyJsPlugin 。

Webpack 4 配置最棒实施

2018/06/22 · JavaScript · webpack

原来的文章出处: Zindex   

Webpack 4 公布已经有一段时间了。Webpack 的版本号已经到来了 4.12.x。但因为 Webpack 官方还尚未产生搬迁指南,在文书档案层面上还存有欠缺,抢先四分之二人对进级 Webpack 依旧壹只雾水。

而是 Webpack 的费用集团曾经写了有些零星的小说,官方网址络也会有了新版配置的文书档案。社区中一些开垦者也早就打响试水,晋级到了 Webpack 4,而且总括成了博客。所以小编也总算去探听了 Webpack 4 的具体情况。以下正是本身对搬迁到 Webpack 4 的局地经验。

本文的首要在:

  • Webpack 4 在安顿上带来了什么样便利?要迁移须要修改配置文件的如何内容?
  • 事先的 Webpack 配置最棒施行在 Webpack 4 那些本子,还适用吗?

如此在组件中更新后,就不会重复 build 那些第三方的财富,

Webpack 4 事先的 Webpack 最棒实施

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

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

其三方库 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 && Long-term caching

Code Splitting 日常须要做这几个事情:

  • 为 Vendor 单独包装(Vendor 指第三方的库可能国有的底子零部件,因为 Vendor 的转移少之甚少,单独打包利于缓存)
  • 为 Manifest (Webpack 的 Runtime 代码)单独包装
  • 为分歧入口的公家事务代码打包(同理,也是为了缓存和加载速度)
  • 为异步加载的代码打一个公共的包

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 引入了 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 仅有付出和生产二种,测量检验情形应该是属于开荒阶段。

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

Webpack 4 的变与不改变

Webpack 4 那几个版本的 API 有部分 breaking change,但不意味着说那一个本子就爆发了天翻地覆的变化。其实变化的点独有多少个。而且只要您留意打听了这几个变化,你一定会赞誉。

搬迁到 Webpack 4 也只须求检查一下 checklist,看看那几个点是或不是都覆盖到了,就足以了。

下一场到上面这八个网址进行深入分析

总结

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 收藏 评论

图片 2

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

有别于开采和生产条件

粗粗的目录结构是如此的:

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 分支里的内容就被移除了。那是一种编写翻译时的死代码优化。这种差别不相同的景况,并给景况变量设置分裂的值的试行,让大家张开了编写翻译时按景况对代码举行针对优化的或是。

Webpack 创设打包优化

Webpack 4 下的拔尖施行

  1. Webpack 创设速度慢
  2. Webpack 打包后的文书体量过大
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'
},

Webpack 创设速度慢

那是不客观的,因为实际我们的第三方库的代码没变,vendor 不应当在大家业务代码变化时产生变化。

Webpack 有个已知难点:

调整和收缩 Webpack 打包后的文书体量大小

  1. 何况独立安排 dll/vendors.js 文件,提须求 webpack.dll.config.js
  2. 修改 package.json
new webpack.optimize.CommonsChunkPlugin({
 name: 'common',
 minChunks: 2,
}),

在 module.rules 中配置 use 为 happypack/loader, 设置 id

实施 npm run dll 未来,会在 dll 目录下生产 多少个文本 vendor-manifest.json ,vendor.dll.js

Webpack.DLLPlugin

此间推荐 webpack-bundle-analyzer 。安装后在 webpack.dev.config.js 中丰盛插件就能够,就能够在每一次运转后活动在网址张开分析结果,如下图

plugins.push( new BundleAnalyzerPlugin());
require('babel-polyfill');
require('classnames');
require('intl');
require('isomorphic-fetch');
require('react');
require('react-dom');
require('immutable');
require('redux');

布署 webpack.dev.config.js 文件,参与三个 DllReferencePlugin 插件,并内定 vendor-manifest.json 文件

在 webpack.dev.config.js 中针对不一致的能源创立多个 HappyPack, 比方 js 1 个,less 1 个,并安装好 id

Webpack 营造打包存在的难题十分重要汇聚于上面四个方面:

  1. webpack/analyse
  2. Webpack Chart

开启 gzip

在 babel-react-optimize 中运用了 babel-plugin-transform-react-remove-prop-types 这么些插件。不奇怪意况下,若是您在代码中并未有援用到零部件的 PropTypes ,则完全没难点。尽管你的零部件用到了,那么使用该插件大概会导致难点。

缓和 bundle.js 体量过大的缓和思路如下:

拆分公共财富

使用 chunkhash 而不用 hash

Happypack

检查未有使用的库,去除 import 援用

修改 html

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

使用 babel-react-optimize对 React 代码进行优化

率先需求对大家全体 bundle 进行深入分析,由什么东西组成及各组成都部队分所占大小。

行使 CompressionPlugin 插件开启 gzip 就可以:

按需打包所用的类库,举例 lodash 、 echart 等

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

另外一个参数 minChunks 表示:在传播公共chunk(commons chunk) 此前所急需包涵的起码数量的 chunks。数量必须大于等于2,也许轻易等于 chunks的数码,传入 Infinity 会马上生成 公共chunk,但中间没有模块。

单身拆分 webpack 自己代码

具体见:

Webpack 4 配置最棒实行。如上就是本文的全部内容,希望对我们的就学抱有助于,也愿意大家多多照料脚本之家。

越来越多关于 CommonChunkPlugin 能够查看 官方文书档案

  1. 生产条件启用压缩等插件,去除不须求插件
  2. 拆分业务代码与第三方库及国有模块
  3. webpack 开启 gzip 压缩
  4. 按需加载

除却,还是可以够将包裹进度输出成json文件

是或不是必要进行这一步优化能够自动依据项目标业务复成本来判别。

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

同 上面包车型地铁拆分第三方库一样,拆分公共能源可以将公用的模块单独打出一个chunk,你能够设置 minChunk 来选取是共用略带次模块才将它们抽离。配置如下:

出于项指标事务代码更动频率异常高,而第三方库的代码变化则相对未有那么频率。假若将专门的职业代码和第三库打包到同一个chunk 的话,在历次塑造的时候,哪怕业务代码只改了一行,即便第三方库的代码未有发生变化,会变成整个 chunk 的 hash 跟上一回分化。那不是我们想要的结果。大家想要的是,假使第三方库的代码未有转换,那在构建的时候也要确认保障相应的 hash 未有暴发变化,进而能动用浏览器缓存,更加好的滋长页面加载质量和抽水页面加载时间。

上边的布署有多少个细节须要专心

经过三十六线程,缓存等艺术进步 rebuild 效能

增进一个 webpack.dll.config.js
根本是用到贰个 DllPlugin 插件,把部分第三方的能源独立包装,相同的时候停放三个manifest.json 配置文件中,

lodash 能够使用babel-plugin-lodash扩充优化。

为此为了确保第三方库不改变的情事下,对应的 vendor.js 的 hash 也要保全不变,大家再 output.filename 中动用了 chunkhash

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

在 scripts 中添加: "dll": "webpack --config webpack.dll.config.js --progress --colors ", 。

  1. hash 是 build-specific ,任何贰个文本的改换都会促成编写翻译的结果分化,适用于开采阶段
  2. chunkhash 是 chunk-specific ,是根据种种 chunk 的内容总括出的 hash,适用于生产

其间 vendros.js 是自个儿定义的什么样第三方库必要放入 vendor 中,如下:

能够动用 Webpack.DDLPlugin , HappyPack 来抓实营造速度。具体参见小铭在 DMP DDLPlugin 的文书档案。原来的小说如下:

当心,要求在 htmlWebpackPlugin 插件中安顿 NODE_ENV 参数

先来探视那二者有啥分歧:

据此能够将第三库的代码单独拆分成 vendor chunk,与事务代码分离。那样纵然业务代码再怎么发生变化,只要第三方库代码未有发生变化,对应的 hash 就不改变。

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

图片 3

首先 entry 配置五个 app 和 vendor 四个chunk

须求专一的是

webpack 自己的 boilerplate 和 manifest 代码大概在每便编写翻译时都会变卦。

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

经过地点的图样解析能够知晓得看看,整个 bundle.js 的组成都部队分及相应的轻重。

下一场经过 CommonsChunkPlugin 拆分第三库

Webpack 4 配置最棒实行。内部的 name 只要不在 entry 就可以,平日使用 "runtime" 或 "manifest" 。

为此大家需求将 webpack 那部分代码分离抽离

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

那致使大家只是在 入口文件 改了一行代码,但编写翻译出的 vendor 和 entry chunk 都变了,因为它们本人都带有那有的代码。

你也许感兴趣的篇章:

  • vue webpack打包优化操作才干
  • vue-cli webpack2项目打包优化分享
  • webpack4.0打包优化计策整理小结

本文由时时app平台注册网站发布于web前端,转载请注明出处:Webpack 4 配置最棒实行

关键词: