初识 webpack
概念
依据 webpack 官方文档,webpack 是一个 module bundler (模块打包器)。初次听到这个概念的时候,可能会一脸蒙蔽:这是个啥?对我的开发有啥影响么?
为了更好理解 webpack,我们需要先了解模块 Module 与打包 Bundle 的具体含义。只有将这两个概念理清楚了才会更清楚 webpack 的作用。
模块 Module
无论使用何种编程语言开发大型应用,最关键的特性就是代码模块化。模块化的必要性在于:提高代码的开发效率,方便代码/功能的维护与重构。在 C++ 里为命名空间,Java 中为包,名称不一样但解决的是同一问题。
但是,最初的 JavaScript 并不是用来编写大规模代码应用的,于是它的规范里面并没有模块化这个标准。对于此,开源开发者提出了一些标准,如 CommoneJs 模块模型、异步模块定义(AMD)以及一些库,来实现模块化。
幸运的是:ES6 为 JavaScript 带来了模块特性。但浏览器实现这一特性还需要一段时间。
打包 Bundle
接着模块化的思路。在 JavaScript 程序开发过程中,模块化会产生很多不同的代码文件(如 js、css等)。举个栗子, SPA 页面 index.html 用到了三个JS文件 和 一个 CSS 文件,那么其通过script标签引入这些文件
//文件结构
|- index.html
|- main.css
| - a.js
| - b.js
| - c.js
//代码演示
// index.html
<!doctype html>
<html>
<head><link href="main.css" rel="stylesheet"></head>
<body>
<div>hello world</div>
<script type="text/javascript" src="a.js"></script>
<script type="text/javascript" src="b.js"></script>
<script type="text/javascript" src="c.js"></script>
</body>
</html>
因为有3 个 js 文件,所以浏览器需要发送三次 http 请求来获取这三个文件。当我们的项目逐渐变大,有几十个到上百个 JavaScript 文件的时候,那问题会更严重。诸多问题都会暴露无遗(如网络延迟等)。
是不是把所有 JavaScript 文件合成一个文件就好了呢?是的。我们确实可以这样做。
但是,矛盾点来了:在开发阶段,我们使用模块化开发;在实际应用中,我们希望能够将多个文件合并为一个文件。这该怎么办呢?
很显然,在开发结束之后,我们需要一个合并的过程。在开发完成后的这个合并过程就是打包。
可以说,webpack 所做的一切工作,都是为了实现模块打包。
Entry 与 Output
将 webpack 理解为模块打包器,将 webpack 工作的过程理解为模块打包的过程。
webpack 的灵活性在于:整个过程的大部分因子我们都是可以配置的,极为个性化。我们先来认识整个过程的头与尾:Entry 属性、Output 属性。
Entry 属性指示 webpack 应该使用哪个模块,来作为构建其内部依赖图的开始。进入入口起点后,webpack 会找出有哪些模块和库是入口起点(直接和间接)依赖的。入口文件可以有多个。根据项目特点,可以以多种方式来配置 Entry。
Output 属性告诉 webpack 在哪里输出它所创建的 bundles,以及如何命名这些文件。它表示的是打包后输出文件的路径。
Loader
这时,我们来了解一下 webpack 的基本工作机制。
在默认情况下,webpack 只能够识别 .js
.json
格式的文件,其他的文件它是无法识别的。对于更多格式的文件,webpack 为我们提供了 Loader 选项,Loader 可以看成是 webpack 不同格式文件的解析器。针对不同的文件格式,我们可以配置不同的 Loader。
Plugins
更进一步,我们需要了解的是:webpack 的运行过程存在一个生命周期的过程。详细的,可以安装lifecycle-webpack-plugin 插件来查看生命周期信息。
plugin 插件,可以在webpack运行到某个阶段的时候(构建流程中的特定时机),帮你做某些事情(注⼊扩展逻辑来改变构建结果),类似于生命周期钩子的作用。
webpack 基本配置
了解了上面的这些概念之后,我们来看 webpack 的基本配置。默认的配置文件是项目目录下的 webpack.config.js 文件。
常用 Loader 配置
对 web 开发而言,常用的需要解析的文件无非是这几种:CSS文件、图片文件、字体文件。那么对应的 loader 配置为:
module: {
rules: [
{
test: /\.css$/,
use: ["style-loader", "css-loader"]
},
{
test: /\.(png|jpe?g|gif)$/,
use: {
loader: "file-loader",
options: {
name: "[name]_[hash:6].[ext]",
outputPath: "images/"
}
}
},
{
test: /\.(eot|ttf|woff|woff2)$/,
use: {
loader: "file-loader",
options: {
name: "[name].[ext]"
}
}
}
}
]
},
常见 Plugin 配置
Plugin 配置,就非常个性化了。随着后期优化的不断加强,我们使用的插件会随之增多。在此只介绍两个插件:
- htmlwebpackplugin :生成创建html入口文件,并将打包后的文件自动插入其中。
- CleanWebpackPlugin :自动清除特定文件夹内容,用于刷新每次打包加载的 output 文件夹。
Babel 配置
有时候我们会使用新的 ECMAScript 规范语法,但浏览器对这个新的语法规范可能不支持。于是需要降级处理。这个时候 Babel 就出现了。
Babel 是 JavaScript 编译器,能将 ES6(或更新的)代码转换成 ES5 代码,让我们开发过程中放⼼使⽤ JS 新特性而不⽤担心兼容性问题。并且还可以通过插件机制根据需求灵活的扩展。
Babel 配置会因为 Babel 版本不同而发生变化。最新的 Babel 7 配置,相比于 Babel 6 简化了不少。
Babel 在执行编译的过程中,会从项目根⽬录下的 .babelrc JSON⽂件中读取配置。没有该文件会从对应 loader 的 options 地⽅读取配置。
基础安装
npm i babel-loader @babel/core @babel/preset-env -D
这几个依赖包的作用如下:
- babel-loader 是 webpack 与 babel 通信的桥梁
- @babel/core 是 babel 的核心功能库
- @babel/preset 里面包含了 es6/es7/es8 转 es5 的转换规则
基础配置
//配置方式一:直接在webpack.config.js 对应 loader 的 options 地⽅配置
{
test: /\.js$/,
use: {
loader: "babel-loader",
options: {
presets: ["@babel/preset-env"]
}
}
}
//配置方式二:项目根⽬录下的 .babelrc 文件配置
//推荐方式二
{
presets: ["@babel/preset-env"]
}
让 babel 支持高级特性
通过上面的几步还不够,默认的 babel 只支持 let 等一些基础的特性转换(只转换语法,不转换新的 API),promise 等高级特性还没有转换过来。这个时候还需要借助 @babel/polyfill,将 ECMAScript 的新特性都装进来,来弥补低版本浏览器中缺失的特性。
npm install --save @babel/polyfill
值得注意的是 @babel/polyfill 是运行时依赖。
按需引入
我们可以尝试全局引入 polyfill 。
// index.js 顶部
import "@babel/polyfill";
会发现打包的体积大了很多。这是因为 polyfill 默认会把所有特性注入进来。我希望当我使用到了 es 6+ 特性的时候,才注入,不用到的不注入,从而减少打包的体积。且对于现代的已经支持高级特性的浏览器,不需要用到 polyfill。因此我们要按需引入 polyfill。
修改.babelrc 文件配置
{
presets: [
[
"@babel/preset-env",
{
targets: { //编译后的代码支持的运行环境对象
edge: "17",
firefox: "60",
chrome: "67",
safari: "11.1"
},
corejs: 2, // 指定核心库版本
useBuiltIns: "usage" //按需注入
}
]
]
}
重点是 useBuiltIns
这个选项。 useBuiltIns
选项是 babel 7 的新功能,这个选项告诉 babel 如何配置 @babel/polyfill 。 它有三个参数可以使⽤:
- entry: 需要在 webpack 的⼊口⽂件⾥ import "@babel/polyfill" ⼀一次。 babel 会根据你的使⽤用情况导入垫片,没有使⽤的功能不会被导⼊入相应的垫⽚。
- usage: 不需要 import ,全⾃动检测,但是要安装 @babel/polyfill 。(试验阶段)
- false: 如果你 import "@babel/polyfill" ,它不会排除掉没有使用的垫⽚,程序体积会庞⼤。(不推荐)
我们使用useBuiltIns: usage
即满足我们的需求。
手写实现Loader 与 Plugin
经过上面的操作,我们已经可以做到了对 webpack 的基本配置,并让其能够运行 ES6 的代码了。在讲 webpack 的性能优化配置之前,我们来尝试一下手写 Loader 与 Plugin 两个模块,以更好地理解这两个模块的作用。别太惊讶,这其实不难。往下看吧:
手写Loader
我们知道,webpack 中的 loader 是各种格式文件的解析器。简单看待 loader,就可以理解为它是一个处理器。对输入进行一番处理(解析)之后,输出结果。
自己尝试编写一个 Loader,这个过程我们可以更好理解 Loader 的工作原理。其过程是比较简单的。
在 webpack 中,Loader 就是一个函数(声明式函数,不能用箭头函数)。它通过参数项获取到源代码,做进一步的修饰处理后,返回处理过的源代码。
就让我们来看看一个最简单的替换源码中文字符串的 loader (它的名字就叫 replaceLoader)是如何写出来的吧:
-
创建原材料(带放入 loader 的源代码,以及 loader):
//index.js console.log("hello 亲爱的"); //replaceLoader.js module.exports = function(source){ console.log(source, this, this.query); return source.replace("亲爱的", "dear"); }
-
在配置文件中使用 loader
//webpack.config.js //node核⼼模块path来处理路径 const path = require('path') ··· module: { rules: [ { test: /\.js$/, use: path.resolve(__dirname,"./loader/replaceLoader.js"), options: { name : "frank" } } ] }, ···
-
如何给 loader 配置参数? loader 如何接收参数?
正如上面的 loader 中,我们可以写入对应的参数放入到 options 中,那么 loader中如何接收到呢?有两种方式:
- this.query //通过 this.query 来接收配置文件传递进来的参数
- loader-utils //该工具可以协助处理包含参数在内的更多细节
-
让 loader 返回多个信息
有的时候我们不仅仅希望 loader 能够返回一个信息,而是可能是更多的信息,比如:报错信息、source-map 信息等。webpack 中的 loader 可以通过调用 this.callback 来返回多个信息。
//replaceLoader.js module.exports = function(source) { const result = source.replace("亲爱的", this.query.name); this.callback(null, result); }; //callback 中可以包含的参数项 //this.callback ( err: Error | null, content: String | Buffer, sourceMap?: SourceMap, meta?: any )
-
让 loader 异步返回
//replaceLoader.js //使用 setTimeout 3sec 再返回 module.exports = function(source) { console.log(this, this.query); const callback = this.async(); setTimeout(() => { const result = source.replace("亲爱的", this.query.name); callback(null, result); }, 3000); };
手写Plugin
经历了自己手写 loader 之后,我们也可以试试自己手写一个简单的 plugin。来加深对于 webpack 的认识。
前面讲过:plugin 插件可以在 webpack 运行到某个阶段的时候(构建流程中的特定时机),帮你做某些事情(注⼊扩展逻辑来改变构建结果)。
在 webpack 中, plugin 必须是一个类(class),里面必须包含一个 apply 函数,该函数接收一个参数:compiler。就这么简单,没有更多的要求了。所以让我们来试试吧:
我们来尝试书写一个在 webpack 打包完成后,往 dist 文件夹增加一个 js 文件的 plugin。很简单没啥真实作用,只是为了演示生成 plugin 的过程而已。
-
创建 ./plugin/add-js-file-webpack-plugin.js
class AddJsFileWebpackPlugin { constructor(){ } apply(compiler){ } } module.exports = AddJsFileWebpackPlugin;
-
配置文件里使用
const AddJsFileWebpackPlugin = require('./plugin/add-js-file-webpack-plugin.js'); ... plugins: [new AddJsFileWebpackPlugin({name:"frank"})] ...
-
如何应用
在上面的配置中,我们看到插件传入了参数
{name:"frank"}
,我们可以在构造器中捕获,并保存起来。然后我们如何使用
apply
函数呢?这个时候就需要结合 webpack 的生命周期函数钩子了。在官网上,可以看到大量的钩子可以供我们使用(有同步执行的钩子,也有异步执行的钩子)。为了演示的目的,我们使用了
compiler.emit
异步钩子和compiler.compile
同步钩子:class AddJsFileWebpackPlugin { constructor(options) { this.name = options.name; console.log(options); } apply(compiler) { compiler.hooks.compile.tap("AddJsFileWebpackPlugin", compilation => { console.log("执行了, "); }); compiler.hooks.emit.tapAsync( "AddJsFileWebpackPlugin", (compilation, cb) => { compilation.assets["finish.js"] = { source: function() { return "hello dear"; }, size: function() { return 20; } }; cb();//异步钩子中,必须调用 cb } ); } } module.exports = AddJsFileWebpackPlugin;
小结
在这篇文章中,我们对 webpack 做了一个基本的认识与了解,并通过简单的配置,让其能够简单运行代码。最后,通过自己手写 Loader 与 Plugin ,更好地认识其中的模块与工作原理。接下来,我们来看看具体如何利用 webpack 来进行优化配置吧!戳这里。