文末有全部内容的下载链接
webpack
的运行流程是一个串行的过程,它的工作流程就是将各个插件串联起来
在运行过程中会广播事件,插件只需要监听它所关心的事件,就能加入到这条webpack
机制中,去改变webpack
的运作,使得整个系统扩展性良好
从启动到结束会依次执行以下三大步骤:
Shell
语句中读取与合并参数,并初始化需要使用的插件和配置插件等执行环境所需要的参数从配置文件和 Shell
语句中读取与合并参数,得出最终的参数
配置文件默认下为webpack.config.js
,也或者通过命令的形式指定配置文件,主要作用是用于激活webpack
的加载项和插件
关于文件配置内容分析,如下注释:
var path = require('path');
var node_modules = path.resolve(__dirname, 'node_modules');
var pathToReact = path.resolve(node_modules, 'react/dist/react.min.js');
module.exports = {
// 入口文件,是模块构建的起点,同时每一个入口文件对应最后生成的一个 chunk。
entry: './path/to/my/entry/file.js',
// 文件路径指向(可加快打包过程)。
resolve: {
alias: {
'react': pathToReact
}
},
// 生成文件,是模块构建的终点,包括输出文件与输出路径。
output: {
path: path.resolve(__dirname, 'build'),
filename: '[name].js'
},
// 这里配置了处理各模块的 loader ,包括 css 预处理 loader ,es6 编译 loader,图片处理 loader。
module: {
loaders: [
{
test: /\.js$/,
loader: 'babel',
query: {
presets: ['es2015', 'react']
}
}
],
noParse: [pathToReact]
},
// webpack 各插件对象,在 webpack 的事件流中执行对应的方法。
plugins: [
new webpack.HotModuleReplacementPlugin()
]
};
webpack
将 webpack.config.js
中的各个配置项拷贝到 options
对象中,并加载用户配置的 plugins
完成上述步骤之后,则开始初始化Compiler
编译对象,该对象掌控者webpack
声明周期,不执行具体的任务,只是进行一些调度工作
class Compiler extends Tapable {
constructor(context) {
super();
this.hooks = {
beforeCompile: new AsyncSeriesHook(["params"]),
compile: new SyncHook(["params"]),
afterCompile: new AsyncSeriesHook(["compilation"]),
make: new AsyncParallelHook(["compilation"]),
entryOption: new SyncBailHook(["context", "entry"])
// 定义了很多不同类型的钩子
};
// ...
}
}
function webpack(options) {
var compiler = new Compiler();
...// 检查options,若watch字段为true,则开启watch线程
return compiler;
}
...
Compiler
对象继承自 Tapable
,初始化时定义了很多钩子函数
根据配置中的 entry
找出所有的入口文件
module.exports = {
entry: './src/file.js'
}
初始化完成后会调用Compiler
的run
来真正启动webpack
编译构建流程,主要流程如下:
compile
开始编译make
从入口点分析模块及其依赖的模块,创建这些模块对象build-module
构建模块seal
封装构建结果emit
把各个chunk输出到结果文件执行了run
方法后,首先会触发compile
,主要是构建一个Compilation
对象
该对象是编译阶段的主要执行者,主要会依次下述流程:执行模块创建、依赖收集、分块、打包等主要任务的对象
当完成了上述的compilation
对象后,就开始从Entry
入口文件开始读取,主要执行_addModuleChain()
函数,如下:
_addModuleChain(context, dependency, onModule, callback) {
...
// 根据依赖查找对应的工厂函数
const Dep = /** @type {DepConstructor} */ (dependency.constructor);
const moduleFactory = this.dependencyFactories.get(Dep);
// 调用工厂函数NormalModuleFactory的create来生成一个空的NormalModule对象
moduleFactory.create({
dependencies: [dependency]
...
}, (err, module) => {
...
const afterBuild = () => {
this.processModuleDependencies(module, err => {
if (err) return callback(err);
callback(null, module);
});
};
this.buildModule(module, false, null, null, err => {
...
afterBuild();
})
})
}
过程如下:
_addModuleChain
中接收参数dependency
传入的入口依赖,使用对应的工厂函数NormalModuleFactory.create
方法生成一个空的module
对象
回调中会把此module
存入compilation.modules
对象和dependencies.module
对象中,由于是入口文件,也会存入compilation.entries
中
随后执行buildModule
进入真正的构建模块module
内容的过程
这里主要调用配置的loaders
,将我们的模块转成标准的JS
模块
在用 Loader
对一个模块转换完后,使用 acorn
解析转换后的内容,输出对应的抽象语法树(AST
),以方便 Webpack
后面对代码的分析
从配置的入口模块开始,分析其 AST
,当遇到require
等导入其它模块语句时,便将其加入到依赖的模块列表,同时对新找出的依赖模块递归分析,最终搞清所有模块的依赖关系
seal
方法主要是要生成chunks
,对chunks
进行一系列的优化操作,并生成要输出的代码
webpack
中的 chunk
,可以理解为配置在 entry
中的模块,或者是动态引入的模块
根据入口和模块之间的依赖关系,组装成一个个包含多个模块的 Chunk
,再把每个 Chunk
转换成一个单独的文件加入到输出列表
在确定好输出内容后,根据配置确定输出的路径和文件名
output: {
path: path.resolve(__dirname, 'build'),
filename: '[name].js'
}
在 Compiler
开始生成文件前,钩子 emit
会被执行,这是我们修改最终文件的最后一个机会
从而webpack
整个打包过程则结束了
HMR
全称 Hot Module Replacement
,可以理解为模块热替换,指在应用程序运行过程中,替换、添加、删除模块,而无需重新刷新整个应用
例如,我们在应用运行过程中修改了某个模块,通过自动刷新会导致整个应用的整体刷新,那页面中的状态信息都会丢失
如果使用的是 HMR
,就可以实现只将修改的模块实时替换至应用中,不必完全刷新整个应用
在webpack
中配置开启热模块也非常的简单,如下代码:
const webpack = require('webpack')
module.exports = {
// ...
devServer: {
// 开启 HMR 特性
hot: true
// hotOnly: true
}
}
通过上述这种配置,如果我们修改并保存css
文件,确实能够以不刷新的形式更新到页面中
但是,当我们修改并保存js
文件之后,页面依旧自动刷新了,这里并没有触发热模块
所以,HMR
并不像 Webpack
的其他特性一样可以开箱即用,需要有一些额外的操作
我们需要去指定哪些模块发生更新时进行HRM
,如下代码:
if(module.hot){
module.hot.accept('./util.js',()=>{
console.log("util.js更新了")
})
}
首先来看看一张图,如下:
上面图中,可以分成两个阶段:
在编写未经过webpack
打包的源代码后,Webpack Compile
将源代码和 HMR Runtime
一起编译成 bundle
文件,传输给 Bundle Server
静态资源服务器
当某一个文件或者模块发生变化时,webpack
监听到文件变化对文件重新编译打包,编译生成唯一的hash
值,这个hash
值用来作为下一次热更新的标识
根据变化的内容生成两个补丁文件:manifest
(包含了 hash
和 chundId
,用来说明变化的内容)和 chunk.js
模块
由于socket
服务器在HMR Runtime
和 HMR Server
之间建立 websocket
链接,当文件发生改动的时候,服务端会向浏览器推送一条消息,消息包含文件改动后生成的hash
值,如下图的h
属性,作为下一次热更细的标识
在浏览器接受到这条消息之前,浏览器已经在上一次 socket
消息中已经记住了此时的 hash
标识,这时候我们会创建一个 ajax
去服务端请求获取到变化内容的 manifest
文件
mainfest
文件包含重新build
生成的hash
值,以及变化的模块,对应上图的c
属性
浏览器根据 manifest
文件获取模块变化的内容,从而触发render
流程,实现局部模块更新
关于webpack
热模块更新的总结如下:
webpack-dev-server
创建两个服务器:提供静态资源的服务(express)和Socket服务随着我们的项目涉及到页面越来越多,功能和业务代码也会随着越多,相应的 webpack
的构建时间也会越来越久
构建时间与我们日常开发效率密切相关,当我们本地开发启动 devServer
或者 build
的时候,如果时间过长,会大大降低我们的工作效率
所以,优化webpack
构建速度是十分重要的环节
常见的提升构建速度的手段有如下:
在使用loader
时,可以通过配置include
、exclude
、test
属性来匹配文件,接触include
、exclude
规定哪些匹配应用loader
如采用 ES6 的项目为例,在配置 babel-loader
时,可以这样:
module.exports = {
module: {
rules: [
{
// 如果项目源码中只有 js 文件就不要写成 /\.jsx?$/,提升正则表达式性能
test: /\.js$/,
// babel-loader 支持缓存转换出的结果,通过 cacheDirectory 选项开启
use: ['babel-loader?cacheDirectory'],
// 只对项目根目录下的 src 目录中的文件采用 babel-loader
include: path.resolve(__dirname, 'src'),
},
]
},
};
在开发中我们会有各种各样的模块依赖,这些模块可能来自于自己编写的代码,也可能来自第三方库, resolve
可以帮助webpack
从每个 require/import
语句中,找到需要引入到合适的模块代码
通过resolve.extensions
是解析到文件时自动添加拓展名,默认情况如下:
module.exports = {
...
extensions:[".warm",".mjs",".js",".json"]
}
当我们引入文件的时候,若没有文件后缀名,则会根据数组内的值依次查找
当我们配置的时候,则不要随便把所有后缀都写在里面,这会调用多次文件的查找,这样就会减慢打包速度
resolve.modules
用于配置 webpack
去哪些目录下寻找第三方模块。默认值为['node_modules']
,所以默认会从node_modules
中查找文件
当安装的第三方模块都放在项目根目录下的 ./node_modules
目录下时,所以可以指明存放第三方模块的绝对路径,以减少寻找,配置如下:
module.exports = {
resolve: {
// 使用绝对路径指明第三方模块存放的位置,以减少搜索步骤
// 其中 __dirname 表示当前工作目录,也就是项目根目录
modules: [path.resolve(__dirname, 'node_modules')]
},
};
alias
给一些常用的路径起一个别名,特别当我们的项目目录结构比较深的时候,一个文件的路径可能是./../../
的形式
通过配置alias
以减少查找过程
module.exports = {
...
resolve:{
alias:{
"@":path.resolve(__dirname,'./src')
}
}
}
DLL
全称是 动态链接库,是为软件在winodw种实现共享函数库的一种实现方式,而Webpack也内置了DLL的功能,为的就是可以共享,不经常改变的代码,抽成一个共享的库。这个库在之后的编译过程中,会被引入到其他项目的代码中
使用步骤分成两部分:
webpack
内置了一个DllPlugin
可以帮助我们打包一个DLL的库文件
module.exports = {
...
plugins:[
new webpack.DllPlugin({
name:'dll_[name]',
path:path.resolve(__dirname,"./dll/[name].mainfest.json")
})
]
}
使用 webpack
自带的 DllReferencePlugin
插件对 mainfest.json
映射文件进行分析,获取要使用的DLL
库
然后再通过AddAssetHtmlPlugin
插件,将我们打包的DLL
库引入到Html
模块中
module.exports = {
...
new webpack.DllReferencePlugin({
context:path.resolve(__dirname,"./dll/dll_react.js"),
mainfest:path.resolve(__dirname,"./dll/react.mainfest.json")
}),
new AddAssetHtmlPlugin({
outputPath:"./auto",
filepath:path.resolve(__dirname,"./dll/dll_react.js")
})
}
在一些性能开销较大的 loader
之前添加 cache-loader
,以将结果缓存到磁盘里,显著提升二次构建速度
保存和读取这些缓存文件会有一些时间开销,所以请只对性能开销较大的 loader
使用此 loader
module.exports = {
module: {
rules: [
{
test: /\.ext$/,
use: ['cache-loader', ...loaders],
include: path.resolve('src'),
},
],
},
};
使用多进程并行运行来提高构建速度
module.exports = {
optimization: {
minimizer: [
new TerserPlugin({
parallel: true,
}),
],
},
};
打包生成 sourceMap
的时候,如果信息越详细,打包速度就会越慢。对应属性取值如下所示:
可以看到,优化webpack
构建的方式有很多,主要可以从优化搜索时间、缩小文件搜索范围、减少不必要的编译等方面入手
loader
用于对模块的"源代码"进行转换,在 import
或"加载"模块时预处理文件
webpack
做的事情,仅仅是分析出各种模块的依赖关系,然后形成资源列表,最终打包生成到指定的文件中。如下图所示:
在webpack
内部中,任何文件都是模块,不仅仅只是js
文件
默认情况下,在遇到import
或者require
加载模块的时候,webpack
只支持对js
和 json
文件打包
像css
、sass
、png
等这些类型的文件的时候,webpack
则无能为力,这时候就需要配置对应的loader
进行文件内容的解析
在加载模块的时候,执行顺序如下:
当 webpack
碰到不识别的模块的时候,webpack
会在配置的中查找该文件解析规则
关于配置loader
的方式有三种:
关于loader
的配置,我们是写在module.rules
属性中,属性介绍如下:
rules
是一个数组的形式,因此我们可以配置很多个loader
每一个loader
对应一个对象的形式,对象属性test
为匹配的规则,一般情况为正则表达式
属性use
针对匹配到文件类型,调用对应的 loader
进行处理
代码编写,如下形式:
module.exports = {
module: {
rules: [
{
test: /\.css$/,
use: [
{ loader: 'style-loader' },
{
loader: 'css-loader',
options: {
modules: true
}
},
{ loader: 'sass-loader' }
]
}
]
}
};
这里继续拿上述代码,来讲讲loader
的特性
从上述代码可以看到,在处理css
模块的时候,use
属性中配置了三个loader
分别处理css
文件
因为loader
支持链式调用,链中的每个loader
会处理之前已处理过的资源,最终变为js
代码。顺序为相反的顺序执行,即上述执行方式为sass-loader
、css-loader
、style-loader
除此之外,loader
的特性还有如下:
package.json
的 main
来将一个 npm 模块导出为 loader,还可以在 module.rules 中使用 loader
字段直接引用一个模块可以通过 loader 的预处理函数,为 JavaScript 生态系统提供更多能力。用户现在可以更加灵活地引入细粒度逻辑,例如:压缩、打包、语言翻译和更多其他特性
在页面开发过程中,我们经常性加载除了js
文件以外的内容,这时候我们就需要配置响应的loader
进行加载
常见的loader
如下:
下面给出一些常见的loader
的使用:
分析 css
模块之间的关系,并合成⼀个 css
npm install --save-dev css-loader
rules: [
...,
{
test: /\.css$/,
use: {
loader: "css-loader",
options: {
// 启用/禁用 url() 处理
url: true,
// 启用/禁用 @import 处理
import: true,
// 启用/禁用 Sourcemap
sourceMap: false
}
}
}
]
如果只通过css-loader
加载文件,这时候页面代码设置的样式并没有生效
原因在于,css-loader
只是负责将.css
文件进行一个解析,而并不会将解析后的css
插入到页面中
如果我们希望再完成插入style
的操作,那么我们还需要另外一个loader
,就是style-loader
把 css-loader
生成的内容,用 style
标签挂载到页面的 head
中
npm install --save-dev style-loader
rules: [
...,
{
test: /\.css$/,
use: ["style-loader", "css-loader"]
}
]
同一个任务的 loader
可以同时挂载多个,处理顺序为:从右到左,从下往上
开发中,我们也常常会使用less
、sass
、stylus
预处理器编写css
样式,使开发效率提高,这里需要使用less-loader
npm install less-loader -D
rules: [
...,
{
test: /\.css$/,
use: ["style-loader", "css-loader","less-loader"]
}
]
在 webpack
中通过 import
方式导入文件内容,该loader
并不是内置的,所以首先要安装
npm install --save-dev raw-loader
然后在 webpack.config.js 中进行配置
module.exports = {
...,
module: {
rules: [
{
test: /\.(txt|md)$/,
use: 'raw-loader'
}
]
}
}
把识别出的资源模块,移动到指定的输出⽬目录,并且返回这个资源在输出目录的地址(字符串)
npm install --save-dev file-loader
rules: [
...,
{
test: /\.(png|jpe?g|gif)$/,
use: {
loader: "file-loader",
options: {
// placeholder 占位符 [name] 源资源模块的名称
// [ext] 源资源模块的后缀
name: "[name]_[hash].[ext]",
//打包后的存放位置
outputPath: "./images",
// 打包后文件的 url
publicPath: './images',
}
}
}
]
可以处理理 file-loader
所有的事情,但是遇到图片格式的模块,可以选择性的把图片转成 base64
格式的字符串,并打包到 js
中,对小体积的图片比较合适,大图片不合适。
npm install --save-dev url-loader
rules: [
...,
{
test: /\.(png|jpe?g|gif)$/,
use: {
loader: "url-loader",
options: {
// placeholder 占位符 [name] 源资源模块的名称
// [ext] 源资源模块的后缀
name: "[name]_[hash].[ext]",
//打包后的存放位置
outputPath: "./images"
// 打包后文件的 url
publicPath: './images',
// 小于 100 字节转成 base64 格式
limit: 100
}
}
}
]
前面两节我们有提到Loader
与Plugin
对应的概念,先来回顾下
从整个运行时机上来看,如下图所示:
可以看到,两者在运行时机上的区别:
在 Webpack
运行的生命周期中会广播出许多事件,Plugin
可以监听这些事件,在合适的时机通过Webpack
提供的 API
改变输出结果
对于loader
,实质是一个转换器,将A文件进行编译形成B文件,操作的是文件,比如将A.scss
或A.less
转变为B.css
,单纯的文件转换过程
在编写 loader
前,我们首先需要了解 loader
的本质
其本质为函数,函数中的 this
作为上下文会被 webpack
填充,因此我们不能将 loader
设为一个箭头函数
函数接受一个参数,为 webpack
传递给 loader
的文件源内容
函数中 this
是由 webpack
提供的对象,能够获取当前 loader
所需要的各种信息
函数中有异步操作或同步操作,异步操作通过 this.callback
返回,返回值要求为 string
或者 Buffer
代码如下所示:
// 导出一个函数,source为webpack传递给loader的文件源内容
module.exports = function(source) {
const content = doSomeThing2JsString(source);
// 如果 loader 配置了 options 对象,那么this.query将指向 options
const options = this.query;
// 可以用作解析其他模块路径的上下文
console.log('this.context');
/*
* this.callback 参数:
* error:Error | null,当 loader 出错时向外抛出一个 error
* content:String | Buffer,经过 loader 编译后需要导出的内容
* sourceMap:为方便调试生成的编译后内容的 source map
* ast:本次编译生成的 AST 静态语法树,之后执行的 loader 可以直接使用这个 AST,进而省去重复生成 AST 的过程
*/
this.callback(null, content); // 异步
return content; // 同步
}
一般在编写loader
的过程中,保持功能单一,避免做多种功能
如less
文件转换成 css
文件也不是一步到位,而是 less-loader
、css-loader
、style-loader
几个 loader
的链式调用才能完成转换
由于webpack
基于发布订阅模式,在运行的生命周期中会广播出许多事件,插件通过监听这些事件,就可以在特定的阶段执行自己的插件任务
在之前也了解过,webpack
编译会创建两个核心对象:
如果自己要实现plugin
,也需要遵循一定的规范:
apply
方法的对象,这样才能访问compiler
实例compiler
和 compilation
对象都是同一个引用,因此不建议修改Webpack
进入下一个流程,不然会卡住实现plugin
的模板如下:
class MyPlugin {
// Webpack 会调用 MyPlugin 实例的 apply 方法给插件实例传入 compiler 对象
apply (compiler) {
// 找到合适的事件钩子,实现自己的插件功能
compiler.hooks.emit.tap('MyPlugin', compilation => {
// compilation: 当前打包构建流程的上下文
console.log(compilation);
// do something...
})
}
}
在 emit
事件发生时,代表源文件的转换和组装已经完成,可以读取到最终将输出的资源、代码块、模块及其依赖,并且可以修改输出资源的内容
随着前端的项目逐渐扩大,必然会带来的一个问题就是性能
尤其在大型复杂的项目中,前端业务可能因为一个小小的数据依赖,导致整个页面卡顿甚至奔溃
一般项目在完成后,会通过webpack
进行打包,利用webpack
对前端项目性能优化是一个十分重要的环节
通过webpack
优化前端的手段有:
terser
是一个JavaScript
的解释、绞肉机、压缩机的工具集,可以帮助我们压缩、丑化我们的代码,让bundle
更小
在production
模式下,webpack
默认就是使用 TerserPlugin
来处理我们的代码的。如果想要自定义配置它,配置方法如下:
const TerserPlugin = require('terser-webpack-plugin')
module.exports = {
...
optimization: {
minimize: true,
minimizer: [
new TerserPlugin({
parallel: true // 电脑cpu核数-1
})
]
}
}
属性介绍如下:
CSS
压缩通常是去除无用的空格等,因为很难去修改选择器、属性的名称、值等
CSS的压缩我们可以使用另外一个插件:css-minimizer-webpack-plugin
npm install css-minimizer-webpack-plugin -D
配置方法如下:
const CssMinimizerPlugin = require('css-minimizer-webpack-plugin')
module.exports = {
// ...
optimization: {
minimize: true,
minimizer: [
new CssMinimizerPlugin({
parallel: true
})
]
}
}
使用HtmlWebpackPlugin
插件来生成HTML
的模板时候,通过配置属性minify
进行html
优化
module.exports = {
...
plugin:[
new HtmlwebpackPlugin({
...
minify:{
minifyCSS:false, // 是否压缩css
collapseWhitespace:false, // 是否折叠空格
removeComments:true // 是否移除注释
}
})
]
}
设置了minify
,实际会使用另一个插件html-minifier-terser
对文件的大小进行压缩,减少http
传输过程中宽带的损耗
npm install compression-webpack-plugin -D
new ComepressionPlugin({
test:/\.(css|js)$/, // 哪些文件需要压缩
threshold:500, // 设置文件多大开始压缩
minRatio:0.7, // 至少压缩的比例
algorithm:"gzip", // 采用的压缩算法
})
一般来说在打包之后,一些图片文件的大小是远远要比 js
或者 css
文件要来的大,所以图片压缩较为重要
配置方法如下:
module: {
rules: [
{
test: /\.(png|jpg|gif)$/,
use: [
{
loader: 'file-loader',
options: {
name: '[name]_[hash].[ext]',
outputPath: 'images/',
}
},
{
loader: 'image-webpack-loader',
options: {
// 压缩 jpeg 的配置
mozjpeg: {
progressive: true,
quality: 65
},
// 使用 imagemin**-optipng 压缩 png,enable: false 为关闭
optipng: {
enabled: false,
},
// 使用 imagemin-pngquant 压缩 png
pngquant: {
quality: '65-90',
speed: 4
},
// 压缩 gif 的配置
gifsicle: {
interlaced: false,
},
// 开启 webp,会把 jpg 和 png 图片压缩为 webp 格式
webp: {
quality: 75
}
}
}
]
},
]
}
Tree Shaking
是一个术语,在计算机中表示消除死代码,依赖于ES Module
的静态语法分析(不执行任何的代码,可以明确知道模块的依赖关系)
在webpack
实现Trss shaking
有两种不同的方案:
两种不同的配置方案, 有不同的效果
配置方法也很简单,只需要将usedExports
设为true
module.exports = {
...
optimization:{
usedExports
}
}
使用之后,没被用上的代码在webpack
打包中会加入unused harmony export mul
注释,用来告知 Terser
在优化时,可以删除掉这段代码
如下面sum
函数没被用到,webpack
打包会添加注释,terser
在优化时,则将该函数去掉
sideEffects
用于告知webpack compiler
哪些模块时有副作用,配置方法是在package.json
中设置sideEffects
属性
如果sideEffects
设置为false,就是告知webpack
可以安全的删除未用到的exports
如果有些文件需要保留,可以设置为数组的形式
"sideEffecis":[
"./src/util/format.js",
"*.css" // 所有的css文件
]
上述都是关于javascript
的tree shaking
,css
同样也能够实现tree shaking
css
进行tree shaking
优化可以安装PurgeCss
插件
npm install purgecss-plugin-webpack -D
const PurgeCssPlugin = require('purgecss-webpack-plugin')
module.exports = {
...
plugins:[
new PurgeCssPlugin({
path:glob.sync(`${path.resolve('./src')}/**/*`), {nodir:true}// src里面的所有文件
satelist:function(){
return {
standard:["html"]
}
}
})
]
}
将代码分离到不同的bundle
中,之后我们可以按需加载,或者并行加载这些文件
默认情况下,所有的JavaScript
代码(业务代码、第三方依赖、暂时没有用到的模块)在首页全部都加载,就会影响首页的加载速度
代码分离可以分出出更小的bundle
,以及控制资源加载优先级,提供代码的加载性能
这里通过splitChunksPlugin
来实现,该插件webpack
已经默认安装和集成,只需要配置即可
默认配置中,chunks仅仅针对于异步(async)请求,我们可以设置为initial或者all
module.exports = {
...
optimization:{
splitChunks:{
chunks:"all"
}
}
}
splitChunks
主要属性有如下:
可以通过InlineChunkHtmlPlugin
插件将一些chunk
的模块内联到html
,如runtime
的代码(对模块进行解析、加载、模块信息相关的代码),代码量并不大,但是必须加载的
const InlineChunkHtmlPlugin = require('react-dev-utils/InlineChunkHtmlPlugin')
const HtmlWebpackPlugin = require('html-webpack-plugin')
module.exports = {
...
plugin:[
new InlineChunkHtmlPlugin(HtmlWebpackPlugin,[/runtime.+\.js/]
}
关于webpack
对前端性能的优化,可以通过文件体积大小入手,其次还可通过分包的形式、减少http请求次数等方式,实现对前端性能的优化
Plugin
(Plug-in)是一种计算机应用程序,它和主应用程序互相交互,以提供特定的功能
是一种遵循一定规范的应用程序接口编写出来的程序,只能运行在程序规定的系统下,因为其需要调用原纯净系统提供的函数库或者数据
webpack
中的plugin
也是如此,plugin
赋予其各种灵活的功能,例如打包优化、资源管理、环境变量注入等,它们会运行在 webpack
的不同阶段(钩子 / 生命周期),贯穿了webpack
整个编译周期
目的在于解决loader
无法实现的其他事
这里讲述文件的配置方式,一般情况,通过配置文件导出对象中plugins
属性传入new
实例对象。如下所示:
const HtmlWebpackPlugin = require('html-webpack-plugin'); // 通过 npm 安装
const webpack = require('webpack'); // 访问内置的插件
module.exports = {
...
plugins: [
new webpack.ProgressPlugin(),
new HtmlWebpackPlugin({ template: './src/index.html' }),
],
};
其本质是一个具有apply
方法javascript
对象
apply
方法会被 webpack compiler
调用,并且在整个编译生命周期都可以访问 compiler
对象
const pluginName = 'ConsoleLogOnBuildWebpackPlugin';
class ConsoleLogOnBuildWebpackPlugin {
apply(compiler) {
compiler.hooks.run.tap(pluginName, (compilation) => {
console.log('webpack 构建过程开始!');
});
}
}
module.exports = ConsoleLogOnBuildWebpackPlugin;
compiler hook
的 tap
方法的第一个参数,应是驼峰式命名的插件名称
关于整个编译生命周期钩子,有如下:
常见的plugin
有如图所示:
下面介绍几个常用的插件用法:
在打包结束后,⾃动生成⼀个 html
⽂文件,并把打包生成的 js
模块引⼊到该 html
中
npm install --save-dev html-webpack-plugin
// webpack.config.js
const HtmlWebpackPlugin = require("html-webpack-plugin");
module.exports = {
...
plugins: [
new HtmlWebpackPlugin({
title: "My App",
filename: "app.html",
template: "./src/html/index.html"
})
]
};
DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title><%=htmlWebpackPlugin.options.title%>title>
head>
<body>
<h1>html-webpack-pluginh1>
body>
html>
在 html
模板中,可以通过 <%=htmlWebpackPlugin.options.XXX%>
的方式获取配置的值
更多的配置可以自寻查找
删除(清理)构建目录
npm install --save-dev clean-webpack-plugin
const {CleanWebpackPlugin} = require('clean-webpack-plugin');
module.exports = {
...
plugins: [
...,
new CleanWebpackPlugin(),
...
]
}
提取 CSS
到一个单独的文件中
npm install --save-dev mini-css-extract-plugin
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
module.exports = {
...,
module: {
rules: [
{
test: /\.s[ac]ss$/,
use: [
{
loader: MiniCssExtractPlugin.loader
},
'css-loader',
'sass-loader'
]
}
]
},
plugins: [
...,
new MiniCssExtractPlugin({
filename: '[name].css'
}),
...
]
}
允许在编译时创建配置的全局对象,是一个webpack
内置的插件,不需要安装
const { DefinePlugun } = require('webpack')
module.exports = {
...
plugins:[
new DefinePlugin({
BASE_URL:'"./"'
})
]
}
这时候编译template
模块的时候,就能通过下述形式获取全局对象
复制文件或目录到执行区域,如vue
的打包过程中,如果我们将一些文件放到public
的目录下,那么这个目录会被复制到dist
文件夹中
npm install copy-webpack-plugin -D
new CopyWebpackPlugin({
parrerns:[
{
from:"public",
globOptions:{
ignore:[
'**/index.html'
]
}
}
]
})
复制的规则在patterns
属性中设置:
from:设置从哪一个源中开始复制
to:复制到的位置,可以省略,会默认复制到打包的目录下
globOptions:设置一些额外的选项,其中可以编写需要忽略的文件
webpack proxy
,即webpack
提供的代理服务
基本行为就是接收客户端发送的请求后转发给其他服务器
其目的是为了便于开发者在开发模式下解决跨域问题(浏览器安全策略限制)
想要实现代理首先需要一个中间服务器,webpack
中提供服务器的工具为webpack-dev-server
webpack-dev-server
是 webpack
官方推出的一款开发工具,将自动编译和自动刷新浏览器等一系列对开发友好的功能全部集成在了一起
目的是为了提高开发者日常的开发效率,只适用在开发阶段
关于配置方面,在webpack
配置对象属性中通过devServer
属性提供,如下:
// ./webpack.config.js
const path = require('path')
module.exports = {
// ...
devServer: {
contentBase: path.join(__dirname, 'dist'),
compress: true,
port: 9000,
proxy: {
'/api': {
target: 'https://api.github.com'
}
}
// ...
}
}
devServetr
里面proxy
则是关于代理的配置,该属性为对象的形式,对象中每一个属性就是一个代理的规则匹配
属性的名称是需要被代理的请求路径前缀,一般为了辨别都会设置前缀为 /api
,值为对应的代理匹配规则,对应如下:
proxy
工作原理实质上是利用http-proxy-middleware
这个http
代理中间件,实现请求转发给其他服务器
举个例子:
在开发阶段,本地地址为http://localhost:3000
,该浏览器发送一个前缀带有/api
标识的请求到服务端获取数据,但响应这个请求的服务器只是将请求转发到另一台服务器中
const express = require('express');
const proxy = require('http-proxy-middleware');
const app = express();
app.use('/api', proxy({target: 'http://www.example.org', changeOrigin: true}));
app.listen(3000);
// http://localhost:3000/api/foo/bar -> http://www.example.org/api/foo/bar
在开发阶段, webpack-dev-server
会启动一个本地开发服务器,所以我们的应用在开发阶段是独立运行在 localhost
的一个端口上,而后端服务又是运行在另外一个地址上
所以在开发阶段中,由于浏览器同源策略的原因,当本地访问后端就会出现跨域请求的问题
通过设置webpack proxy
实现代理请求后,相当于浏览器与服务端中添加一个代理者
当本地发送请求的时候,代理服务器响应该请求,并将请求转发到目标服务器,目标服务器响应数据后再将数据返回给代理服务器,最终再由代理服务器将数据响应给本地
在代理服务器传递数据给本地浏览器的过程中,两者同源,并不存在跨域行为,这时候浏览器就能正常接收数据
注意:服务器与服务器之间请求数据并不会存在跨域行为,跨域行为是浏览器安全策略限制
模块化是一种处理复杂系统分解为更好的可管理模块的方式
可以用来分割,组织和打包应用。每个模块完成一个特定的子功能,所有的模块按某种方法组装起来,成为一个整体(bundle
)
在前端领域中,并非只有webpack
这一款优秀的模块打包工具,还有其他类似的工具,例如Rollup
、Parcel
、snowpack
,以及最近风头无两的Vite
通过这些模块打包工具,能够提高我们的开发效率,减少开发成本
这里没有提及gulp
、grunt
是因为它们只是定义为构建工具,不能类比
Rollup
是一款 ES Modules
打包器,从作用上来看,Rollup
与 Webpack
非常类似。不过相比于 Webpack
,Rollup
要小巧的多
现在很多我们熟知的库都都使用它进行打包,比如:Vue
、React
和three.js
等
举个例子:
// ./src/messages.js
export default {
hi: 'Hey Guys, I am zce~'
}
// ./src/logger.js
export const log = msg => {
console.log('---------- INFO ----------')
console.log(msg)
console.log('--------------------------')
}
export const error = msg => {
console.error('---------- ERROR ----------')
console.error(msg)
console.error('---------------------------')
}
// ./src/index.js
import { log } from './logger'
import messages from './messages'
log(messages.hi)
然后通过rollup
进行打包
$ npx rollup ./src/index.js --file ./dist/bundle.js
可以看到,代码非常简洁,完成不像webpack
那样存在大量引导代码和模块函数
并且error
方法由于没有被使用,输出的结果中并无error
方法,可以看到,rollup
默认开始Tree-shaking
优化输出结果
因此,可以看到Rollup
的优点:
但缺点也十分明显,加载其他类型的资源文件或者支持导入 CommonJS
模块,又或是编译 ES
新特性,这些额外的需求 Rollup
需要使用插件去完成
综合来看,rollup
并不适合开发应用使用,因为需要使用第三方模块,而目前第三方模块大多数使用CommonJs
方式导出成员,并且rollup
不支持HMR
,使开发效率降低
但是在用于打包 JavaScript
库时,rollup
比 webpack
更有优势,因为其打包出来的代码更小、更快,其存在的缺点可以忽略
Parcel ,是一款完全零配置的前端打包器,它提供了 “傻瓜式” 的使用体验,只需了解简单的命令,就能构建前端应用程序
Parcel
跟 Webpack
一样都支持以任意类型文件作为打包入口,但建议使用HTML
文件作为入口,该HTML
文件像平时一样正常编写代码、引用资源。如下所示:
<!-- ./src/index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Parcel Tutorials</title>
</head>
<body>
<script src="main.js"></script>
</body>
</html>
main.js文件通过ES Moudle
方法导入其他模块成员
// ./src/main.js
import { log } from './logger'
log('hello parcel')
// ./src/logger.js
export const log = msg => {
console.log('---------- INFO ----------')
console.log(msg)
}
运行之后,使用命令打包
npx parcel src/index.html
执行命令后,Parcel
不仅打包了应用,同时也启动了一个开发服务器,跟webpack Dev Server
一样
跟webpack
类似,也支持模块热替换,但用法更简单
同时,Parcel
有个十分好用的功能:支持自动安装依赖,像webpack
开发阶段突然使用安装某个第三方依赖,必然会终止dev server
然后安装再启动。而Parcel
则免了这繁琐的工作流程
同时,Parcel
能够零配置加载其他类型的资源文件,无须像webpack
那样配置对应的loader
打包命令如下:
npx parcel src/index.html
由于打包过程是多进程同时工作,构建速度会比Webpack
快,输出文件也会被压缩,并且样式代码也会被单独提取到单个文件中
可以感受到,Parcel
给开发者一种很大的自由度,只管去实现业务代码,其他事情用Parcel
解决
Snowpack,是一种闪电般快速的前端构建工具,专为现代Web
设计,较复杂的打包工具(如Webpack
或Parcel
)的替代方案,利用JavaScript
的本机模块系统,避免不必要的工作并保持流畅的开发体验
开发阶段,每次保存单个文件时,Webpack
和Parcel
都需要重新构建和重新打包应用程序的整个bundle
。而Snowpack
为你的应用程序每个文件构建一次,就可以永久缓存,文件更改时,Snowpack
会重新构建该单个文件
下图给出webpack
与snowpack
打包区别:
在重新构建每次变更时没有任何的时间浪费,只需要在浏览器中进行HMR更新
vite ,是一种新型前端构建工具,能够显著提升前端开发体验
它主要由两部分组成:
其作用类似webpack
+ webpack-dev-server
,其特点如下:
vite
会直接启动开发服务器,不需要进行打包操作,也就意味着不需要分析模块的依赖、不需要编译,因此启动速度非常快
利用现代浏览器支持ES Module
的特性,当浏览器请求某个模块的时候,再根据需要对模块的内容进行编译,这种方式大大缩短了编译时间
原理图如下所示:
在热模块HMR
方面,当修改一个模块的时候,仅需让浏览器重新请求该模块即可,无须像webpack
那样需要把该模块的相关依赖模块全部编译一次,效率更高
相比上述的模块化工具,webpack
大而全,很多常用的功能做到开箱即用。有两大最核心的特点:一切皆模块和按需加载
与其他构建工具相比,有如下优势:
Webpack
最初的目标是实现前端项目的模块化,旨在更高效地管理和维护项目中的每一个资源
最早的时候,我们会通过文件划分的形式实现模块化,也就是将每个功能及其相关状态数据各自单独放到不同的 JS
文件中
约定每个文件是一个独立的模块,然后再将这些js
文件引入到页面,一个script
标签对应一个模块,然后调用模块化的成员
<script src="module-a.js">script>
<script src="module-b.js">script>
但这种模块弊端十分的明显,模块都是在全局中工作,大量模块成员污染了环境,模块与模块之间并没有依赖关系、维护困难、没有私有空间等问题
项目一旦变大,上述问题会尤其明显
随后,就出现了命名空间方式,规定每个模块只暴露一个全局对象,然后模块的内容都挂载到这个对象中
window.moduleA = {
method1: function () {
console.log('moduleA#method1')
}
}
这种方式也并没有解决第一种方式的依赖等问题
再后来,我们使用立即执行函数为模块提供私有空间,通过参数的形式作为依赖声明,如下
// module-a.js
(function ($) {
var name = 'module-a'
function method1 () {
console.log(name + '#method1')
$('body').animate({ margin: '200px' })
}
window.moduleA = {
method1: method1
}
})(jQuery)
上述的方式都是早期解决模块的方式,但是仍然存在一些没有解决的问题。例如,我们是用过script
标签在页面引入这些模块的,这些模块的加载并不受代码的控制,时间一久维护起来也十分的麻烦
理想的解决方式是,在页面中引入一个JS
入口文件,其余用到的模块可以通过代码控制,按需加载进来
除了模块加载的问题以外,还需要规定模块化的规范,如今流行的则是CommonJS
、ES Modules
从后端渲染的JSP
、PHP
,到前端原生JavaScript
,再到jQuery
开发,再到目前的三大框架Vue
、React
、Angular
开发方式,也从javascript
到后面的es5
、es6、7、8、9、10
,再到typescript
,包括编写CSS
的预处理器less
、scss
等
现代前端开发已经变得十分的复杂,所以我们开发过程中会遇到如下的问题:
而webpack
恰巧可以解决以上问题
webpack
是一个用于现代JavaScript
应用程序的静态模块打包工具
这里的静态模块指的是开发阶段,可以被 webpack
直接引用的资源(可以直接被获取打包进bundle.js
的资源)
当 webpack
处理应用程序时,它会在内部构建一个依赖图,此依赖图对应映射到项目所需的每个模块(不再局限js
文件),并生成一个或多个 bundle
webpack
的能力:编译代码能力,提高效率,解决浏览器兼容问题
模块整合能力,提高性能,可维护性,解决浏览器频繁请求文件的问题
万物皆可模块能力,项目维护性增强,支持不同种类的前端模块类型,统一的模块化方案,所有资源文件的加载都可以通过代码控制
更多面试题
https://download.csdn.net/download/suli77/87411227