webpack4.x升级摘要

时间 2019-12-10

标签 webpack4.x webpack 升级摘要繁體版

原文原文链接

一：前端工程化的发展

好久之前，互联网行业有个职位叫作 “软件开发工程师” 在那个时代，你们可能会蒙，放在现今社会，你们会以为这个职位太过笼统，因此在此提一下那个时候的互联网行业状态。javascript

那个时候的APP还不是ios/安卓多数是嵌入式应用（和网页不要紧使用c++或java开发）后续到了Symbian时代出现了可移植的sis[x]类型应用，曾经一统移动APP市场。
那个时候css百分之90仍是用来作布局
那个时候js仅仅是为了相似弹出提示的功能而存在的
那个时候从服务器 - 数据库 - 业务逻辑 - 页面全都由所谓的 “软件开发工程师” 来完成
因此你们没必要问软件开发工程师具体是干啥的，我只能说啥都干

1：我的对前端开发的体验过程

第一个阶段就是开始对着W3C的文档，拿着txt文本文件一个字母字母的敲着代码，那个年代，真的单纯舒服，上来就是一个项目的文件夹，而后就开始img、js、css三个完美的文件夹，再接上一个index.html，就开始到网上各类下载类库jquery、underscore.js，而后手动的引入各类类库，固然过程也伴随着痛苦。php

每次来一个项目就开始创建各类繁琐的文件夹，和拷贝复制类库
引入完类库的时候发现控制台报错，$ is not defined，依赖关系出错，部分类库须要把jquery做为依赖
新写一个页面就须要去从新复制其余页面的header资源，维护变的困难（彻底没有组件化的想法）
部分css3属性须要本身不断的手动添加样式前缀
最大的问题再维护的时候，不敢轻易的去动一些类库的引入，不清楚各个库以前的依赖关系

第二个阶段就是在接触到Vue的时候直接上vue-cli的时候，几行脚本就能够启动本地开发服务和打包线上资源，初次尝试了webpack这个打包工具，好像对其余问题不须要作过多的考虑，直接开始业务开发，其余的事情cli都帮助处理好了。vue init webpack helloWorld， cd helloWorld && cnpm install && npm run dev，真香警告，对工程化只知其一;不知其二，可是好用，方便css

前端须要一些工具来处理重复的大量繁琐的事 (资源压缩代码混淆 css前缀），之前会用Gulp等Task处理任务
前端须要一些须要用一些预处理器来处理样式文件，less之前用第三方工具去编译 -> less提供的命令行去编译-> 配置到webpack中自动化实时编译
前端须要更加细粒度的配置一下代码体积的优化，代码混淆压缩的操做
前端部分业务越多，代码量越多（文件体积越大）须要作文件合并，压缩以及按需加载等
开发阶段依然在本地开发，但同时保持和线上API的同步，为此咱们须要本地服务器（能够是静态服务器）代理转发（Nginx webpack-dev-server node-server等方式）

第三个阶段就是给公司项目升级webpack过程当中体验到了更细粒度的控制工程，体验工程化的过程，实际的体验到了工程化为咱们作的事情html

模块化开发，不用在担忧以往开发方式带来的全局做用域的污染问题，固然以往也能够经过闭包来实现私有变量的概念
组件化开发，代码重用度高，便于维护
多了构建，编译过程，能够在适当的时间去作一些提升工程质量的任务，好比代码规范的检测，经常使用的是Eslint (Airbnb, Prettier 规范等)
提升开发效率，好比css浏览器前缀的自动添加，使用postCss甚至能够提早使用一些好用的东西，好比css变量的概念
经过chunkHash，contentHash 等实现资源的缓存
根据工程代码经过合理的代码分割提高用户体验，作到按需加载，甚至能够在将来作一些用户使用的习惯，作一些提早的预加载

二：webpack的基本使用

1：webpack和Grunt / Gulp的区别

这两类是不一样的东西，一个能够理解为是任务执行器而另一个是模块打包器，任务执行器是能够自动化的执行一些之前你须要手动操做的过程，见下面简单的代码前端

// coffee 源码
console.log 'Hello World'
  
//coffee转 js coffee -c a.coffee
  
(function(){
  console.log('Hello World');
}).call(this);
  
//执行编译压缩 uglify -s a.js -o a.min.js
(function(){console.log("Hello World")}).call(this);

coffee须要编译成浏览器支持的js，你须要手动的去执行上面的几个命令，若是如今须要去修改源码，在Hello World 后面加上一个！，加完你须要手动的去执行两条命令重复的去编译操做。以 gulp 为例，编写 gulpfile.js来帮助咱们完成重复的工做vue

gulp   = require('gulp')
coffee = require('gulp-coffee')
uglify = require('gulp-uglify')
rename = require('gulp-rename')
  
file = './src/js/a.coffee'
  
gulp.task('coffee', function(){
    gulp.src(file)
        .pipe(coffee())  // 编译
        .pipe(uglify())  // 压缩
        .pipe(rename({
            extname: ".min.js"
        }))
        .pipe(gulp.dest('./build/js'))
  
gulp.task('watch', function(){
    gulp.watch(file, ['coffee'])
})
  
gulp.task('default', ['coffee'])

我只要执行一下 gulp watch 就能够检测到coffee文件的变化，而后为你执行一系列的自动化操做，一样的操做也发生在less, scss, 这些css的预处理器上。在修改到源文件的状况下的编译，压缩这些重复操做都交由它来完成，在我看来Grunt / Gulp 算是一个可以自动化执行一些繁琐重复的操做，提升生产效率，算是一个任务执行器。java

这些操做一样也能够由webpack完成，接下来咱们看一下官网给出的webpack的定义。node

webpack is a module bundler

官方给出的解释是，webpack是一个模块打包器，不是一个任务执行器，它是能够配合Grunt / Gulp 使用的，相关连接webpack集成。webpack打包器(bundler)帮助你生成准备用于部署的 JavaScript 和样式表，将它们转换为适合浏览器的可用格式。例如，JavaScript的压缩、chunk split和懒加载，以提升性能。因此webpack和Gulp/Grunt之间是有必定功能的重叠，可是处理合适，是能够一块儿配合工做的，不存在所谓的谁替代谁，只是在某些场景下webpack的可以独当一面，完成了Grunt/ Gulp的功能。jquery

2：webpack3.x 和 webpack4.x 的对比

rollup以及Parcel的出现，号称零配置，足以让一个配置成本比较高的webpack出现了4.0版本，固然也号称零配置使用，开箱即用，如今来一块儿看看webpack4.x和3.x比较大的区别，先给出一个Release连接webpack Release v4.0.0下面简要的介绍一些大的改动webpack

Node环境的升级，不在支持node 4.0的版本，最低支持6.11.5
配置增长了mode：'production', 'development', 'none' ，所谓的开箱即用的支持点，在不一样的mode下开启了一些默认的优化手段
生产模式开启了各类优化去生成bundle文件、默认开启做用域提高、process.env.NODE_ENV设置为production
开发模式优化内部rebuild流程，提高开发效率和体验
删除了和添加了一些配置项，NoEmitOnErrorsPlugin、ModuleConcatenationPlugin（default in production mode）、NamedModulesPlugin（default in development mode） ---> 转到optimization.*的配置项
原生支持处理JSON文件格式，不须要json-loader
内置的插件 uglifyjs-webpack-plugin 升级到了 V1, 而V1是能够支持并行处理压缩混淆JS的，webpack3以前的内置依赖的版本0.4.6 不支持并行处理。经常使用手段使用webpack-uglify-parallel插件并行处理，利用多核CPU的优点，升级到webapck4能够不须要了，使用默认也能够
一个算是比较大的改动，webpack3.x的ComoonsChunkPlugin废弃，代替的是optimization.splitChunks 和 optimization.runtimeChunk (会在下文着重介绍)

3：webpack4.x 的一些基本概念

首先先看下图总体了解一下webpack的一些经常使用配置项

接下来简单的了解一下webpack的一些基本概念

mode：三种模式，production、development、none。设置mode，webpack会根据mode作相应的优化
entry：入口，webpack会从入口递归寻找全部的依赖，造成依赖关系图（dependency graph）。目前应用主要分为单入口和多入口，直观上表现为通过webpack处理以后是一个JS文件仍是多个JS文件（在没有代码分割以及懒加载的前提下）
output：输出，主要经过filename来定义生成chunk的命名，能够经过标识符[name]、[contenthash]、[chunkhash]来实现资源的缓存，chunkFileName针对async chunk
loader：loader用于对模块的源代码进行转换。既然是模块打包器，那么就会出现依赖各类各样的文件和内容，图片，字体，它们须要通过编译才能被浏览器识别(less、sass,、stylus、ES201五、ts等module) ，都须要经过对应的loader转换成现代浏览器支持的东西。loader支持链式传递，loader运行在Node.js中，而且可以执行任何可能的操做，好比存在一些不是用来转换文件的loader，thread-loder（多个node进程处理loader转码文件，提升编译速度）
plugin：插件和loader不一样的地方在于，loader是针对模块，好比import以及require的module文件进行转码。plugin是在webapck的complier整个生命周期中起做用，在这个编译阶段你能够在提供的hook中执行你须要的任何操做。好比htmlWebpackPligun插件，能够在webpack编译emit文件的钩子中，生成html去使用这些webpack生成的JS Chunk
module：module的概念能够理解为一个个须要加载的文件，Js也好，Css文件也好，都须要通过loader处理，module里面的rules去就是配置module须要什么loader去处理
chunks：两种，init chunks（这些chunks文件是会以script标签添加到htmlWebpackPlugin生成的html文件中，固然也能够经过插件内置到html文件中，好比mainifest文件）和async chunks。初始化chunks是从提供给webapck的entries中开始递归的寻找依赖的module，生成的一个chunks。异步的chunks能够理解为是须要按需加载的，主要能够分为如下3个来源：第1、从初始化的chunk中抽出去的代码，造成的chunk文件（这个就是webapck的splitChunk和runtimeChunk的配置）。第2、能够经过webpack识别的特定语法require.ensure (vue-router中懒加载的写法)。第3、ES6的动态导入import(/chunkname/)
optimization：这是webpack4.x出现的一个优化类的配置项，经常使用配置项：splitChunk、runtimeChunk（下文介绍）、minimize、noEmitOnErrors、namedModules、sideEffects（配合tree shaking使用）等等
resolve：如上图，这个配置会增量的告知webpack如何的去寻找依赖，alias（避免一些深层次引用module代码的别名）、modules（从哪些目录寻找依赖）、extensions（module的扩展名）、mainFields（第三方类库存在多个版本的时候，优先使用哪一个版本）。alias能够手动指定第三方库的使用，好比当Vue没有用CDN的时候，若是从node_modules引用，引入的代码是runtime运行时的代码，是没有包含解析单文件.vue的template部分的功能，这个时候须要依赖它的其余版本，手动指定，常见于用Vue-cli去生成项目架构的时候，发现alias默认有一项，告知webpack引入Vue的时候module的位置是vue/dist/vue.esm.js（包含了解析template的代码）。mainFields的使用是针对第三方类库使用各类模块化写法以及语法。有ES6的mport、export的，也有CommonJs的模块导出。有压缩的min.js也有Ts版本的，这些会在package.json中看到，至于引入第三方模块的引入那个版本，对于一些成熟的类库好比Vue，Vue-router等有多个版本，能够经过设置mainFields告知webpack从package.json中的那个字段导入类库。ES6的improt、export存在静态分析，配合tree shaking使用，这也是webpack号称能提速98%的缘由，可是目前的情况是第三方库良莠不齐，不少都没有提供ES6模块导出的版本，全部目前效果还不是很理想
externals：指定外部扩展。从bundle中排除依赖，好比项目一些基本不会变动版本的第三方类库，经过引用CDN资源，常见Vue、VueRouter、element-ui、echart等等类库
devServer：开发模式的配置。在webpack4.x以前的版本经过node的express框架搭建的本地服务器，配合webpack-dev-middleware和webpack-hot-middleware搭建的开发环境。如今能够经过webapck-dev-server类库结合devServer配置项去开启本地开发环境，这个类库封装了express的操做，同时内部使用了webpack-dev-middleware。给出配置连接：devServer配置项

三：项目webpack升级流程

先简短的介绍一下项目，升级的项目为多入口项目，每一个module模块代码一个入口，而后共用不少业务组件

*/build
    webpack.base.conf.js   // dev和prod共用部分
    webpack.dev.conf.js     // dev模式下特有配置
    webapck.prod.conf.js   // prod模式下特有配置
*/common
    components // 多个模块共用的组件
    assets // 静态资源    
*/src
    module1  // 模块1的代码
        index.js  // 模块1代码的入口
    module2  // 模块2的代码
    module3  // 模块3的代码
*/mock
    mock-xxx.js  // mock api的接口
*/config // 配置文件
    index.js
    dev.js
    prod.js

1：package.json依赖的管理

升级webpack，安装webpack-cli。全局安装npm-check-updates，查看package.json中可升级的依赖的版本。

cnpm install -g npm-check-updates  //全局安装
  
// 在项目根目录下执行ncu
ncu
  
// 可升级的依赖，列举部分依赖状况
axios 0.17.1 --> 0.18.0
webpack  3.5.5 --> 4.16.5
webpack-merge 4.1.0 --> 4.1.4
  
// 升级webpack 安装webpack-cli
cnpm install webpack webpack-cli --save-dev
  
// 升级相应的loader和plugin
cnpm install url-loader file-loader vue-loader sass-loader css-loader babel-loader html-webpack-plugin --save-dev

2：修改webpack配置

公司使用的vue-cli2.0的脚手架生成的项目，简单的列举关于webpack的目录，针对须要可进行自行调整

*/build
    webpack.base.conf.js   // dev和prod共用部分
    webpack.dev.conf.js     // dev模式下特有配置
    webapck.prod.conf.js   // prod模式下特有配置

// 经过webpack-merge合并配置输出最后的webpack配置

1:增长mode模式

// webpack.dev.conf.js 开发模式的配置 开启webpack默认的配置优化
mode: 'development'
  
// webpack.prod.conf.js 生产模式的配置
mode: 'production'

2：升级vue-loader，vue-loaderv.15版本和以前的有所区别，vue-loader不在使用自身的配置，而是解析.vue文件以后使用webpack里配置的loader，详细文档见Vue-loader的使用，补充一点：在.vue 文件中style提供的scoped标记，就是经过vue-loader去实如今template中加入了适当的hash，配合样式去作到组件内样式的独立

// webpack.config.js
const VueLoaderPlugin = require('vue-loader/lib/plugin')  // 插件解析.vue文件把template script style 分别交给webpack配置的loader去处理
 
module.exports = {
  // ...
  plugins: [
    new VueLoaderPlugin()
  ]
}

3：部分webpack的插件已经配置停用。若有的话，按照提示删除掉，好比module里的loaders，webpack4再也不支持。而后部分插件转化为经过optimazation 进行配置，主要配置点在于code split以及mainifest文件的提取，一样见下文splitChunks和runtimeChunks的分析

4：开发模式加入devServer。项目是否须要经过手动node搭建本地服务器，取决因而否须要node层面去处理其余东西，在公司项目中启动服务前有两个操做，编译scss文件（皮肤文件），以及mock文件夹（mock接口），因此仍是保留了手动档搭建node层面启动服务，其实彻底能够有webpck-dev-server的before，after配置项完成

// 下面代码块针对devServer的部分配置项作说明，结合相关知识进行分析
devServer: {
   contentBase: path.join(__dirname, '../static'),   // 静态资源提供，不是webpack生成的bundle,生成的bundle在内存中见注释1
   host: host || 'localhost',  // 主机名，若是你但愿服务器外部可访问，须要设置为0.0.0.0，默认localhost
   port: process.env.PORT || port, // 端口号
   historyApiFallback: true,      // handle fallback for HTML5 history API 了解一下这个东西见注释2
   proxy: proxyTable,    // 后端接口转发见注释3
   hot: true,   // 热更新见注释4
   quiet: true,  // webpack打包信息省略
   publicPath: assetsPublicPath,  // bundle 的位置 outpath： publicPath 相似
   clientLogLevel: "none"  // HRM WDS 在浏览器控制台的输出
}
  
// 注释1：写过express的就知道有一个指定static中间件用来指定资源目录的
const express = require('express')
const app = express()
  
app.use(staticPath, express.static(xxx))  // xxx/js/vendor.js，就能够经过localhost:prot/staticPath/js/vendor.js访问相关静态资源。因此contentBase就是利用express静态中间价提供个一种访问静态资源文件的能力
  
// 注释2：vue-router的history模式充分利用 history.pushState API 来完成 URL 跳转而无须从新加载页面 example: history.pushState({a:1}, '测试', '/attendance/index') ，而后内部去处理相应的router对象的展现Vue页面和逻辑，因此这就是你顺着程序点路由能够进去，可是刷新的时候，就显示404的缘由，由于该路由在服务器上不是真实存在的，而是在index.html中经过JS去解析模拟的，这就须要咱们生产模式下生产的dist文件全部的请求都转发到index.html。处理方式：在服务器上经过nignx 代理，或者起一个express服务，经过第三方类库 connect-history-api-fallback，固然也能够原生Node去写，此时Node只是一个文件服务器
  
const http = require('http')
const fs = require('fs')
const httpPort = 80
 
http.createServer((req, res) => {
  fs.readFile('index.htm', 'utf-8', (err, content) => {
    if (err) {
      console.log('We cannot open "index.htm" file.')
    }
 
    res.writeHead(200, {
      'Content-Type': 'text/html; charset=utf-8'
    })
 
    res.end(content)
  })
}).listen(httpPort, () => {
  console.log('Server listening on: http://localhost:%s', httpPort)
})
  
// 注释3：请求代理，经常被问起跨域请求有哪些方案，jsonp、CORS(后端配合)、window iframe等方式，还有一个就是经过node代码转发请求，服务端请求不存在跨域的概念，webpack中能够node本身使用http-proxy-middleware 去进行代理，本次更新使用的wbepack-dev-server模块同时也依赖了http-proxy-middleware的库，目前Node不做为纯后端，而是做为中间代码，链接纯后端(java php)和前端。
  
// 注释4：热更新，它容许在运行时更新各类模块，而无需进行彻底刷新，目前的公司项目都是纯刷新的方式，热更新HRM，这个是须要你是用的loader或插件帮助你完成，他们能监听webpck complier期间得钩子，而后给出相应源码更新后须要patch，推送到前端，打补丁，而后实现热更新，而不是刷新整个页面去从新加载页面。好处天然提升开发效率，在修改.vue文件的tempalte和style以及script中不是vue生命周期函数时，是可以保留到当时的vue的各类状态

5：针对生产模式的优化配置，废弃生产模式中使用的优化插件，转为webpack4的optimization.* 配置

NoEmitOnErrorsPlugin // 编译错误跳过编译阶段，不生成文件（default in production）
ModuleConcatenationPlugin // 做用域提高，加快代码执行（default in production）
NamedModulesPlugin // 默认的module在打包进入chunks的时候都会以module.id 为标识（这个是随着依赖递增的），这会影响到缓存，使用这个插件将会使用文件的路径做为标识，详细见splitChunks and runtimeChunk分析
CommonsChunkPlugin // 最为晦涩难懂的webpack插件，做用代码分割，被splitChunks && runtimeChunks代替

下面为升级以前的配置

// 依赖module（require， import 导入的文件）来自node_modules且以.js 结尾的文件将会被打包到名为vendor的bundle中
new webpack.optimize.CommonsChunkPlugin({
    name: 'vendor',
    minChunks: function (module, count) {
        // any required modules inside node_modules are extracted to vendor
        return (
            module.resource &&
            /\.js$/.test(module.resource) &&
            module.resource.indexOf(
                path.join(__dirname, '../node_modules')
            ) === 0
        )
    }
}),
 
// 在vendor的bundle中把manifest提取出来（mainifest算是webpack实现的在浏览器端进行模拟加载模块和具体加载逻辑的代码块，这个最好拆出来，否则无法作缓存，具体见到长效缓存分析）
new webpack.optimize.CommonsChunkPlugin({
    name: 'manifest',
    chunks: ['vendor']
})
  
// 打包以后就会生成一个vendor.js （里面有着来自node_modules 的第三方类库）和 mainifest.js （具体加载逻辑）

升级以后，完成原有的配置很简单，简单的照着API实现便可，本次升级伴随着两个重点，开发模式的rebuild时间，生成环境的打包文件体积和时间，因此还须要作其余优化

某些第三方类库只有某个module才加载，好比只有module1中用mint-ui，这是能够单独提出来一个chunk或者直接就加载到module1这个入口的init chunk中 ----> 配置层面
某些公共组件好比component下公共组件layout在基本每一个系统模块所有都条用了，能够考虑拉出来共用，减小重复代码量 ----> 配置层面
利用ES的语法去动态的引入模块import('a.js').then(module => {})去懒加载一个模块，好比只有在某些vue中才会用到的vue-qrcode-component的类库，这个类库不该该出如今vendor中（来自node_modules） ----> 代码层面

optimization: {
  splitChunks: {
    cacheGroups: {
        // module只要知足下面就会从原来的chunks中抽取出来打包到对应的chunks之中
        // 这个vendors是在至少同时有两个initial Chunk中引入的来自node_modules的第三方类库会被打包到chunks-vendors中
        vendors: {
            name: 'chunk-vendors',
            test: /[\\\/]node_modules[\\\/]/,
            priority: -10,
            minChunks: 2,    // 至少同时有几个chunk知足才会有可能从这些chunks中提取一些代码到新的chunk中，也就是至少两个共用才会提取，否则就直接打包都所在module的init chunk中
            chunks: 'initial'  // chunk的概念：代码分割这些操做做用于那些chunk文件，initial是经过提供给webpack入口生成的chunks， async是经过以前提到的import()  路由懒加载造成的chunk， all就是全部的chunk文件
        },
        // 这个common跟上面的区别在于没有test检测module来源，只是只要有两个chunk共用就是提取出来，很显然就范围来说，下面的大于上面，这时候到底这个来自node_modules的module进入哪一个chunk，取决于priority(优先级)，谁高进入哪一个chunk
        common: {
            name: 'chunk-common',
            minChunks: 2,
            priority: -12,
            chunks: 'initial',
            minSize: 0
        }
    }
  },
  runtimeChunk: {
    name: 'manifest'
  }
}
 
// 好比某些第三方类库只在某个Vue文件中使用，经过动态引入import('vue-qrcode-component').then() 一个类库只在一个地方用，彻底没有必要打包到vendor中（由于vue-qrcode-component 来自node_module）
// import 就是新建一个chunk  这个chunk是没有名字的，须要经过/* webpackChunkName: "loadsh"*/ 生成这个loadsh的chunk.name
import(/* webpackChunkName: "loadsh"*/ 'loadsh').then(m => {
    const _ = m.default
    console.log(_.join(['hello', 'world']))
})

总结：通常通过这几步骤就能完成一个webapck项目的升级，对于本身项目的复杂的地方须要额外的处理，写着写着发现篇幅愈来愈长了，把上文一直出现的splitChunk和runtimeChunk留到下个篇幅着重介绍一下。在公司作升级以前，给的指标不只仅是升级框架，还须要在dev模式开发的rebuild的速度更快（修改一个地方，rebuild的时间12s左右才能看到效果，痛苦，能够经过lessModule来解决），在prod模式下打包的项目文件体积减少已经打包所须要的时间更短（一次测试环境发布须要5，6分钟）。如今vue-cli3.0已经出现了，找时间把vue-cli3.0源码给你们分析一下，简单的包装了一下操做