持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第2天,点击查看活动详情
得不得奖的无所谓希望能强迫自己闯一关╮( ̄▽ ̄)╭,上次更文未通关,这次继续
前言
记录 webpack
的学习总结,梳理笔者学习Webpack的过程,
从webpack的工作原理 - 了解部分笔者常用的loader/plugin - 学习实现自定义loader/plugin
有误请多多指正,附上女神图保命 [手动狗头]\
编写的内容将收入专栏webpack学习专栏
学习已完成
- 1.Webpack 安装与使用了解
- 2.Webpack 工作流程原理
- 3.Webpack 核心
1.Webpack 安装与使用了解
本质上,webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时,它会递归地构建一个依赖关系图(dependency graph),其中包含应用程序需要的每个模块,然后将所有这些模块打包成一个或多个 bundle。
1.初始化项目
使用 npm init -y
进行初始化(也可以使用 yarn
)。
要使用 webpack
,必然需要安装 webpack
、webpack-cli
npm i -D webpack webpack-cli
版本号
"webpack": "^5.73.0",
"webpack-cli": "^4.9.2"
从 wepack4.x
开始, webpack
是开箱即用的,在不引入任何配置文件的情况下就可以使用。
新建 src/index.js
使用 npx webpack --mode=development
进行构建,默认是 production
模式,这里笔者使用 development
模式。
执行后可以看到项目下多了个 dist
目录,有一个打包出来的文件 main.js
在 dist
里
但这个笔者还未引入转移 ES6+ 为 ES5,浏览器只认 ES5,现在是没法在浏览器用的
如下图还是原先的 class 形式
2.引入babel-loader 转译 ES6+ 代码为 ES5
a. 安装 babel-loader
还有结合 babel-loader
相关的一些库
npm install babel-loader -D
npm install @babel/core @babel/preset-env @babel/plugin-transform-runtime @babel/runtime @babel/runtime-corejs3 -D
版本号
"@babel/core": "^7.18.2",
"@babel/plugin-transform-runtime": "^7.18.2",
"@babel/preset-env": "^7.18.2",
"@babel/runtime": "^7.18.3",
"@babel/runtime-corejs3": "^7.18.3",
"babel-loader": "^8.2.5",
b. 根文件新建 webpack.config.js
配置 babel-loader
module.exports = {
module: {
rules: [
{
test: /\.jsx?$/,
use: {
loader: 'babel-loader',
// options: 配置可写在此处,也可新建 .babelrc 文件,将配置写在 .babelrc 里
},
exclude: /node_modules/ // 排除 node_modules 目录
}
]
}
}
由于 node_modules
目录通常不需要我们去编译所以可以排除,给 loader
指定 include
或是 exclude
,指定其中一个即可,排除可以提升编译效率。
新建 .babelrc 文件写入配置
{
"presets": ["@babel/preset-env"],
"plugins": [
[
"@babel/plugin-transform-runtime",
{
"corejs": 3
}
]
]
}
再次执行 npx webpack --mode=development
,即可发现 dist/main.js
与之前未配置 babel-loader
不同,这才是浏览器认的代码
3.配置mode
module.exports = {
mode: "development",
module: {
...
}
}
即可不再使用 npx webpack --mode=development
,直接 npx webpack
开发过程当然要区分开发和生产环境
development
:将process.env.NODE_ENV
的值设置为development
production
:将process.env.NODE_ENV
的值设置为production
4. 浏览器中运行
a. 引入html-webpack-plugin
和 cross-env
, 并配置
npm install html-webpack-plugin@5.5.0 cross-env@7.0.3 -D
PS: 关于 cross-env ---------- 当您使用这样设置环境变量时,大多数 Windows 命令提示符都会阻塞
NODE_ENV=production
。(例外是[Bash on Windows],它使用本机 Bash。)同样,windows 和 POSIX 命令使用环境变量的方式也有所不同。在 POSIX 中,使用:$ENV_VAR
,在 Windows 上,使用%ENV_VAR%
cross-env使您可以拥有一个命令,而无需担心为平台正确设置或使用环境变量。就像在 POSIX 系统上运行时一样设置它,并且cross-env会正确设置它,可以很好的是适配多个平台,无需根据平台来设置相对应的变量
根路径新建 public/index.html
, public/config.js
// public/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">
<% if(htmlWebpackPlugin.options.config.header) { %>
<style>
body,html{
background-color: bisque;
}
</style>
<% } %>
<title><%= (htmlWebpackPlugin.options.config.title) %></title>
</head>
<body>
</body>
<% if(htmlWebpackPlugin.options.config.footer) { %>
<script type="text/javascript">
console.log('tywd')
</script>
<% } %>
</html>
- html-webpack-plugin 的 config 的妙用
有时脚手架不仅自己使用,还提供给其它业务使用,
html
文件的可配置性可能很重要, 比如:有专门的部门提供M页的公共头部/公共尾部,埋点jssdk以及分享的jssdk等等,但是不是每个业务都需要这些内容。
一个功能可能对应多个 js
或者是 css
文件,如果每次都是业务自行修改 public/index.html
文件,也挺麻烦的。首先他们得搞清楚每个功能需要引入的文件,然后才能对 index.html
进行修改。
此时可以增加一个配置文件,业务通过设置 true
或 false
来选出自己需要的功能,再根据配置文件的内容,为每个业务生成相应的 html
文件
//public/config.js 除了以下的配置之外,这里面还可以有许多其他配置,例如,pulicPath 的路径等等
module.exports = {
dev: {
template: {
title: '哈哈哈哈哈哈',
header: false,
footer: false
}
},
build: {
template: {
title: '呵呵呵呵呵呵',
header: true,
footer: true
}
}
}
// webpack.config.js
const HtmlWebpackPlugin = require('html-webpack-plugin');
const isDev = process.env.NODE_ENV === 'development';
const config = require('./public/config')[isDev ? 'dev' : 'build'];
module.exports = {
// ...
plugins: [
// plugins是存放所有的webpack插件的数组
new HtmlWebpackPlugin({
template: './public/index.html',
filename: 'index.html', // 打包后的文件名
minify: {
removeAttributeQuotes: false, // 是否删除属性的双引号
collapseWhitespace: false, // 是否折叠空白
},
hash: true, // 是否加上hash,默认是 false
config: config.template
})
const isDev = process.env.NODE_ENV === 'development';
const config = require('./public/config')[isDev ? 'dev' : 'build'];
]
}
// package.json
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"dev": "cross-env NODE_ENV=development webpack",
"build": "cross-env NODE_ENV=production webpack"
},
接着执行 npm run build
或者 npm run dev
对比下可看到 dist/index.html
的title
是配置的 config.js 中配置的不同的内容,而 npm run build
,生成的 index.html
文件中引入了对应的 css
和 js
。
b. 浏览器中实时展示效果
npm install webpack-dev-server@4.9.1 -D
修改下 package.json
文件的 scripts
:
"scripts": {
"dev": "cross-env NODE_ENV=development webpack-dev-server",
"build": "cross-env NODE_ENV=production webpack"
}
在 webpack.config.js
中进行 webpack-dev-server
的其它配置,例如指定端口号,设置浏览器控制台消息,是否压缩等等:
//webpack.config.js
module.exports = {
//...
devServer: {
// hot: true, // 启用热替换,默认为true
// liveReload: true, // 默认情况下,当检测到文件更改时,开发服务器将重新加载/刷新页面。
// host: '0.0.0.0', // 域名
open: true, // 启动后自动打开默认浏览器运行
port: '8090', // 默认是8080
compress: true, // 是否启用 gzip 压缩
client: {
logging: 'error', // 允许在浏览器中设置日志级别,若不想看见一开始的一些打印启用热更新的提示将不会显示,而是有 error 才显示,还有其他属性 warn | info
overlay: {
errors: true, // 默认为true,启用 overlay 后,当编译出错时,会在浏览器窗口全屏输出错误
warnings: false, // 默认为true,警告 不输出全屏提示
},
},
}
}
在 src/index.js
最后一行随便写点代码,如下
// index.js
// ...
const apple = new Fruit('apple');
console.log('tywd哈哈哈哈哈哈哈'); // 输入该行代码
执行 npm run dev
,启动正常,如果再往页面中增加点内容,正常刷新(也就是说不需要进行任何配置就可以使用了)。
PS: 有一个问题: console 打印的代码行数和 index.js 中实际的代码行并不对应,点击后,也定位不到源代码位置
修改
webpack.config.js
配置
// webpack.config.js
module.exports = {
devtool: 'eval-cheap-module-source-map' // 开发环境下使用
}
点击可定位到对应代码行
此处已经完成基本配置,不再阐述,接着看下工作流程
2.Webpack 工作流程原理
流程原理介绍
先看一张 webpack 构建流程生命周期图
Webpack 的运行流程是一个串行的过程,从启动到结束会依次执行以下流程 :
1. 初始化参数:事件节点- entry-options
从配置文件和 Shell 语句中读取与合并参数,得出最终的参数。
2. 开始编译:事件节点- compile
用上一步得到的参数初始化 Compiler 对象,加载所有配置的插件, 执行 Compiler 对象的 run() 方法开始执行编译。
3. 确定入口:事件节点- make
根据配置中的 entry 找出所有的入口文件。
4. 编译模块:事件节点- build-module
从入口文件出发,调用所有配置的 Loader 对 module 进行转换,再找出该 module 依赖的 module,再递归本步骤直到所有入口依赖的文件都经过本步骤的处理。
5. 完成模块编译:事件节点- after-compile
使用 Loader 转换完所有 module 后,得到了每个 module 被转换后的最终内容以及它们之间的依赖关系。
6. 输出资源:事件节点 - emit
根据 entry 和 module 之间的依赖关系,组装成一个个包含多个模块的 Chunk,再把每个 Chunk 转换成一个单独的文件加入到输出列表,这步是可以修改输出内容的最后机会。
7. 输出完成:事件节点 - after-emit
在确定好输出内容后,根据配置 output 确定输出的路径和文件名,把文件内容写入到文件系统。
8. Webpack事件监听 通过 Plugin 执行
在以上过程中,Webpack 会在特定的时间点广播出特定的事件,也就是webpack的事件钩子里广播,插件 plugin 在监听到感兴趣的事件后会执行特定的逻辑,并且插件可以调用 Webpack 提供的 API 改变 Webpack 的运行结果。
以上过程简单概括如下
Webpack 启动后会从 Entry 里配置的 Module 开始递归解析 Entry 依赖的所有 Module。
每找到一个 Module, 就会根据配置的 Loader 去找出对应的转换规则,对 Module 进行转换后,再解析出当前 Module 依赖的 Module。
这些模块会以 Entry 为单位进行分组,一个 Entry 和其所有依赖的 Module 被分到一个组也就是一个 Chunk。
最后 Webpack 会把所有 Chunk 转换成文件输出。
在整个流程中 Webpack 会在恰当的时机执行 Plugin 里定义的逻辑。
流程细节
Webpack 的构建流程可以分为以下三大阶段:
- 初始化:启动构建,读取与合并配置参数,加载 Plugin,实例化 Compiler。
- 编译:从 Entry 发出,针对每个 Module 串行调用对应的 Loader 去翻译文件内容,再找到该 Module 依赖的 Module,递归地进行编译处理。
- 输出:对编译后的 Module 组合成 Chunk,把 Chunk 转换成文件,输出到文件系统。
如果只执行一次构建,以上阶段将会按照顺序各执行一次。但在开启监听模式下,流程将变为如下:
初始化阶段
事件名 | 解释 |
---|---|
初始化参数 | 从配置文件和 Shell 语句中读取与合并参数,得出最终的参数。 这个过程中还会执行配置文件中的插件实例化语句 new Plugin() 。 |
实例化 Compiler | 用上一步得到的参数初始化 Compiler 实例,Compiler 负责文件监听和启动编译。Compiler 实例中包含了完整的 Webpack 配置,全局只有一个 Compiler 实例。 |
加载插件 | 依次调用插件的 apply 方法,让插件可以监听后续的所有事件节点。同时给插件传入 compiler 实例的引用,以方便插件通过 compiler 调用 Webpack 提供的 API。 |
environment | 开始应用 Node.js 风格的文件系统到 compiler 对象,以方便后续的文件寻找和读取。 |
entry-option | 读取配置的 Entrys,为每个 Entry 实例化一个对应的 EntryPlugin,为后面该 Entry 的递归解析工作做准备。 |
after-plugins | 调用完所有内置的和配置的插件的 apply 方法。 |
after-resolvers | 根据配置初始化完 resolver,resolver 负责在文件系统中寻找指定路径的文件。 |
编译阶段
事件名 | 解释 |
---|---|
run | 启动一次新的编译。 |
watch-run | 和 run 类似,区别在于它是在监听模式下启动的编译,在这个事件中可以获取到是哪些文件发生了变化导致重新启动一次新的编译。 |
compile | 该事件是为了告诉插件一次新的编译将要启动,同时会给插件带上 compiler 对象。 |
compilation | 当 Webpack 以开发模式运行时,每当检测到文件变化,一次新的 Compilation 将被创建。一个 Compilation 对象包含了当前的模块资源、编译生成资源、变化的文件等。Compilation 对象也提供了很多事件回调供插件做扩展。 |
make | 一个新的 Compilation 创建完毕,即将从 Entry 开始读取文件,根据文件类型和配置的 Loader 对文件进行编译,编译完后再找出该文件依赖的文件,递归的编译和解析。 |
after-compile | 一次 Compilation 执行完成。 |
invalid | 当遇到文件不存在、文件编译错误等异常时会触发该事件,该事件不会导致 Webpack 退出。 |
在编译阶段中,最重要的要数 compilation 事件了,因为在 compilation 阶段调用了 Loader 完成了每个模块的转换操作,在 compilation 阶段又包括很多小的事件,它们分别是:
事件名 | 解释 |
---|---|
build-module | 使用对应的 Loader 去转换一个模块。 |
normal-module-loader | 在用 Loader 对一个模块转换完后,使用 acorn 解析转换后的内容,输出对应的抽象语法树(AST),以方便 Webpack 后面对代码的分析。 |
program | 从配置的入口模块开始,分析其 AST,当遇到 require 等导入其它模块语句时,便将其加入到依赖的模块列表,同时对新找出的依赖模块递归分析,最终搞清所有模块的依赖关系。 |
seal | 所有模块及其依赖的模块都通过 Loader 转换完成后,根据依赖关系开始生成 Chunk。 |
输出阶段
事件名 | 解释 |
---|---|
should-emit | 所有需要输出的文件已经生成好,询问插件哪些文件需要输出,哪些不需要。 |
emit | 确定好要输出哪些文件后,执行文件输出,可以在这里获取和修改输出内容。 |
after-emit | 文件输出完毕。 |
done | 成功完成一次完成的编译和输出流程。 |
failed | 如果在编译和输出流程中遇到异常导致 Webpack 退出时,就会直接跳转到本步骤,插件可以在本事件中获取到具体的错误原因。 |
在输出阶段已经得到了各个模块经过转换后的结果和其依赖关系,并且把相关模块组合在一起形成一个个 Chunk。 在输出阶段会根据 Chunk 的类型,使用对应的模版生成最终要要输出的文件内容。
3.Webpack 核心
虽然Webpack 功能强大且配置项多,但只要你理解了其中的几个核心概念,就能随心应手地使用它。 Webpack 有以下几个核心概念。
此处只讲些概念,具体实现,笔者后续更新学习
Entry:入口
Webpack 执行构建的第一步将从 Entry 开始,可抽象成输入。
Module:模块
在 Webpack 里一切皆模块,一个模块对应着一个文件。Webpack 会从配置的 Entry 开始递归找出所有依赖的模块。
Loader:模块转换器
用于把模块原内容按照需求转换成新内容。
Chunk:代码块
一个 Chunk 由多个模块组合而成,用于代码合并与分割。
Plugin:扩展插件
在 Webpack 构建流程中的特定时机注入扩展逻辑来改变构建结果或做你想要的事情。
Output:输出结果
在 Webpack 经过一系列处理并得出最终想要的代码后输出结果。
最后
参考文章
# 90 行代码的webpack,你确定不学吗?
# 带你深度解锁Webpack系列(基础篇)
# 深入浅出的webpack
代码地址
以上的方式总结只是自己学习总结,有其他方式欢迎各位大佬评论
渣渣一个,欢迎各路大神多多指正,不求赞,只求监督指正( ̄. ̄)
有关文章经常被面试问到可以帮忙留下言,小弟也能补充完善完善一起交流学习,感谢各位大佬(~ ̄▽ ̄)~