霖呆呆的六个自定义Webpack插件详解

你盼世界，我盼望你无bug。Hello 大家好！我是霖呆呆！

有很多小伙伴在打算学写一个webpack插件的时候，就被官网上那一长条一长条的API给吓到了，亦或者翻阅了几篇文章之后但还是不知道从何下手。

而呆呆认为，当你了解了整个插件的创建方式以及执行机制之后，那些个长条的API就只是你后期用来开发的"工具库"而已，我需要什么，我就去文档上找，大可不必觉得它有多难 😊。

本篇文章会教大家从浅到深的实现一个个webpack插件，案例虽然都不是什么特别难的插件，但是一旦你掌握了如何写一个插件的方法之后，剩下的就只是在上面做增量了。呆呆还是那句话："授人予鱼不如授人予渔"。

OK👌，让我们来看看通过阅读本篇文章你可以学习到：

所有文章内容都已整理至 LinDaiDai/niubility-coding-js 快来给我Star呀😊~

此系列记录了我在webpack上的学习历程。如果你也和我一样想要好好的掌握webpack，那么我认为它对你是有一定帮助的，因为教材中是以一名webpack小白的身份进行讲解， 案例demo也都很详细， 涉及到：

建议先mark再花时间来看。

（其实这个系列在很早之前就写了，一直没有发出来，当时还写了一大长串前言可把我感动的，想看废话的可以点这里：GitHub地址，不过现在让我们正式开始学习吧）

所有文章webpack版本号^4.41.5, webpack-cli版本号^3.3.10。

(本章节教材案例GitHub地址: LinDaiDai/webpack-example/tree/webpack-custom-plugin ⚠️：请仔细查看README说明)

好了，我已经准备好阅读呆呆的这篇文章然后写一个炒鸡牛x的插件了，赶紧的。

额，等等，在这之前我们不是得知道需要怎么去做吗？我们总是听到的插件插件的，它到底是个啥啊？

对象？函数？类？

小伙伴们不妨结合我们已经用过的一些插件来猜猜，比如HtmlWebpackPlugin，我们会这样使用它：

可以看到，这很明显的就是个构造函数，或者是一个类嘛。我们使用new就可以实例化一个插件的对象。并且，这个函数或者类是可以让我们传递参数进去的。

那你脑子里是不是已经脑补出一个轮廓了呢？

知道了plugin大概的轮廓，让我们从构建的角度来看看它。插件不同于loader一个很大的区别就是，loader它是一个转换器，它只专注于转换这一个领域，例如babel-loader能将ES6+的代码转换为ES5或以下，以此来保证兼容性，那么它是运行在打包之前的。

而plugin呢？你会发现市场上有各种让人眼花缭乱的插件，它可能运行在打包之前，也可能运行在打包的过程中，或者打包完成之后。总之，它不局限于打包，资源的加载，还有其它的功能。所以它是在整个编译周期都起作用。

那么如果让我们站在一个编写插件者的角度上来看的话，是不是在编写的时候需要明确两件事情：

所以这时候我们就得清楚这几个硬知识点：

(看不懂？问题不大，呆呆也是从官网cv过来的，不过后面会详细讲到它们哦)

compiler 对象代表了完整的 webpack 环境配置。这个对象在启动 webpack 时被一次性建立，并配置好所有可操作的设置，包括 options，loader 和 plugin。当在 webpack 环境中应用一个插件时，插件将收到此 compiler 对象的引用。可以使用它来访问 webpack 的主环境。

compilation 对象代表了一次资源版本构建。当运行 webpack 开发环境中间件时，每当检测到一个文件变化，就会创建一个新的 compilation，从而生成一组新的编译资源。一个 compilation 对象表现了当前的模块资源、编译生成资源、变化的文件、以及被跟踪依赖的状态信息。compilation 对象也提供了很多关键时机的回调，以供插件做自定义处理时选择使用。

钩子的本质其实就是事件

老规矩，为了能更好的让我们掌握本章的内容，我们需要本地创建一个案例来进行讲解。

创建项目的这个过程我就快速的用指令来实现一下哈：

(mkdir：创建一个文件夹；touch：创建一个文件)

OK👌，此时项目目录变成了：

接着让我们给src/index.js随便加点东西意思一下，省得太空了：

src/index.js

webpack.config.js也简单的来配置一下吧，这些应该都是基础了，之前有详细说过了哟：

(clean-webpack-plugin插件会在我们每次打包之前自动清理掉旧的dist文件夹，对这些内容还不熟悉的小伙伴得再看看这篇文章了：跟着"呆妹"来学webpack(基础篇))

另外还需要在package.json中配置一条打包指令哈：

这里的"webpack"实际上是"webpack --config webpack.config.js"的缩写，这点在基础篇中也有说到咯。

--mode development就是指定一下环境为开发环境，因为我们后续可能有需要看到打包之后的代码内容，如果指定了为production的话，那么webpack它会自动开启UglifyJS的也就是会对我们打包成功之后的代码进行压缩输出，那一坨一坨的代码我们就不利于我们查看了。

好的了，基本工作已经准备完毕了，让我们动手来编写我们的第一个插件吧。

这个插件案例主要是为了帮助你了解插件大概的创建流程。

从易到难，让我们来实现这么一个简单的功能：

在刚刚的案例目录中新建一个plugins文件夹，然后在里面创建上我们的第一个插件: No1-webpack-plugin：

现在依照前面所说的插件的结构，以及我们的需求，可以写出以下代码：

plugins/No1-webpack-plugin.js:

接着，让我们来看看如何使用它，也就是：

webpack.config.js:

OK👌，代码已经编写完啦，快npm run build一下看看效果吧：

可以看到，控制台已经在夸你"good boy!"了😄。

那么让我们回到刚刚的那段自定义插件的代码中：

plugins/No1-webpack-plugin.js:

注意到这里，我们一共是做了这么三件事情，也就是我在代码中的注释。

很显然，为了能拿到webpack.config.js中我们传递的那个参数，也就是{ msg: 'good boy!' }，我们需要在构造函数中定义一个实例对象上的属性options。

并且在prototype.apply中呢：

所以，现在你的思维是不是已经很清晰了呢？我们想要编写一个插件，只需要这么几步：

那么除了用构造函数的方式来创建插件，是否也可以用类呢？让我们一起来试试，将刚刚的代码改动一下：

plugins/No1-webpack-plugin.js:

这时候你执行打包指令效果也是一样的哈。这其实也很好理解，class它不就是咱们构造函数的一个语法糖吗，所以它肯定也可以用来实现一个插件啦。

不过不知道小伙伴们注意到了，在我们刚刚输出"good boy!"的上面，还有一段小小的警告：

如果你和呆呆一样，开始看的官方文档是 《编写一个插件》这里的话，那么现在请让我们换个方向了戳这里了： 《Plugin API》。

但并不是说上面的文档就不能看了，我们依然还是可以通过阅读它来了解更多插件相关的知识。

既然官方都推荐我们用compiler.hooks了，那我们就遵循呗。不过如果你直接去看Plugin API的话对新手来说好像又有点绕，里面的Tapable、compiler、compile、compilation它们直接到底是存在怎样的关系呢？

没关系，呆呆都会依次的进行讲解。

现在让我们将No1-webpack-plugin使用compiler.hooks改造一下吧：

plugins/No1-webpack-plugin.js:

可以看到，第三版中，关键点就是在于：

它替换了我们之前的：

让我们来拆分一下compiler.hooks.done.tap('No1', () => {})：

所以让我们连起来理解这段代码的意思就是：

现在我们虽然会写一个简单的插件了，但是对于上面的一些对象、属性啥的好像还不是很懂耶。想要一口气吃完一头大象🐘是有点难的哦(而且那样也是犯法的)，所以接下来让我们来大概了解一下这些Tapable、compiler等等的东西是做什么的😊。

首先是Tapable这个东西，我看了一下网上有很多对它的描述：

当然这些说法肯定都是对的哈，所以总结一下：

其实如果你去看了它Git上的文档的话，它就是暴露了9个Hooks类，以及3种方法(tap、tapAsync、tapPromise)，可用于为插件创建钩子。

9种Hooks类与3种方法之间的关系：

对于Hooks类你大可不必全都记下，一般来说你只需要知道我们要用的每种钩子它们实际上是有类型区分的，而区分它们的就是Hooks类。

如果你想要清楚它们之前的区别的话，呆呆这里也有找到一个解释的比较清楚的总结：

Sync*

Async*

(总结来源：XiaoLu-写一个简单webpack plugin所引发的思考)

而对于这三种方法，我们必须得知道它们分别是做什么用的：

OK👌，听了霖呆呆这段解释之后，我相信你起码能看得懂官方文档-compiler 钩子这里面的钩子是怎样用的了：

就比如，我现在想要注册一个compile的钩子，根据官方文档，我发现它是SyncHook类型的钩子，那么我们就只能使用tap来注册它。如果你试图用tapAsync的话，打包的话你就会发现控制台已经报错了，比如这样：

（额，不过我在使用compiler.hooks.done.tapAsync()的时候，查阅文档上它也是SyncHook类，但是却可以用tapAsync方法注册，这边呆呆也有点没搞明白是为什么，有知道的小伙伴还希望可以评论区留言呀😄）

接下来就得说一说插件中几个重要的东西了，也就是这一小节的标题里的这三个东西。

首先让我们在官方的文档上找寻一下它们的足迹：

可以看到，这几个属性都长的好像啊，而且更过分的是，compilation竟然还有两个同名的，你这是给👴整真假美猴王呢？

那么呆呆这边就对这几个属性做一下说明。

首先对于文档左侧菜单上的compiler钩子和compilation钩子(也就是第一个和第四个)我们在之后称它们为Compiler和Compilation好了，也是为了和compile做区分，其实我认为你可以把"compiler钩子"理解为"compiler的钩子"，这样会更好一些。

所以你现在可以看到它俩的区别了，一个是代表了整个构建的过程，一个是代表构建过程中的某个模块。

还有很重要的一点，它们两都是扩展至我们上面👆提到的Tapable类，这也就是为什么它两都能有这么多生命周期钩子的原因。

再来看看两个小写的compile和compilation，这两个其实就是Compiler对象下的两个钩子了，也就是我们可以通过这样的方式来调用它们：

区别在于：

(为什么感觉还是没太读懂它们的意思呢？别急，呆呆会在下个例子中来进行说明的)

这个插件案例主要是为了帮你理解Compiler、Compilation、compile、compilation四者之间的关系。

还是在上面👆那个项目中，让我们在plugins文件夹下再新增一个插件，叫做No2-webpack-plugin：

plugins/No2-webpack-plugin.js:

在这个插件中，我分别调用了compile和compilation两个钩子函数，等会让我们看看会发生什么事情。

同时，把webpack.config.js中的No1插件替换成No2插件：

webpack.config.js:

现在项目的目录结构是这样的：

OK👌，来执行npm run build看看：

哈哈哈😄，是不是给了你点什么启发呢？

我们最终生成的dist文件夹下会有两个文件，那么compilation这个钩子就被调用了两次，而compile钩子就只被调用了一次。

有小伙伴可能就要问了，我们这里的src下明明就只有一个index.js文件啊，为什么最终的dist下会有两个文件呢？

别忘了，在这个项目中我们可是使用了html-webpack-plugin这个插件的，它会帮我自动创建一个html文件。

为了验证这个compilation是跟着文件的数量走的，我们暂时先把new HtmlWebpackPlugin给去掉看看：

试试效果？

这时候，compilation就只执行一次了，而且dist中也没有再生成html文件了。

(当然，我这里只是为了演示哈，在确定完了之后，我又把html-webpack-plugin给启用了)

想必上面两个钩子函数的区别大家应该都搞懂了吧，接下来就让我们看看Compiler和Compilation这两个对象的区别。

通过查看官方文档，我们发现，刚刚用到的compiler.hooks.compilation这个钩子，是能够接收一个参数的：

貌似这个形参的名字就是叫做compilation，它和Compilation对象是不是有什么联系呢？或者说，它就是一个Compilation？。

OK👌，我就假设它是吧，接下来我去查看了一下compilation钩子，哇，这钩子的数量是有点多哈，随便挑个顺眼的来玩玩？额，翻到最下面，有个chunkAsset，要不就它吧：

可以看到这个钩子函数是有两个参数的：

接着让我们来改写一下No2-webpack-plugin插件：

src/No2-webpack-plugin.js:

我们做了这么几件事：

如果和我们猜测的一样，每个Compilation对象都对应着一个输出资源的话，那么当我们执行npm run build之后，控制台肯定会打印出两个chunk以及两个filename。

一个是index.html，一个是main.bundle.js。

OK👌，来瞅瞅。

现在看看你的控制台是不是打印出了一大长串呢？呆呆这里简写一下输出结果：

可以看到，确实是有两个Chunk对象，还有两个文件名称。

只不过index.html不是按照我们预期的输出为"index.html"，而是输出为了__child-HtmlWebpackPlugin_0，这点呆呆猜测是html-webpack-plugin插件本身做了一些处理吧。

如果大家把这两个对象打印在控制台上的话会发现有一大长串，呆呆这边找到了一份比较全面的对象属性的清单，大家可以看一下：

(图片与总结来源：编写一个自己的webpack插件plugin)

Compiler 对象包含了 Webpack 环境所有的的配置信息，包含 options，hook，loaders，plugins 这些信息，这个对象在 Webpack 启动时候被实例化，它是全局唯一的，可以简单地把它理解为 Webpack 实例；Compiler中包含的东西如下所示：

Compilation 对象包含了当前的模块资源、编译生成资源、变化的文件等。当 Webpack 以开发模式运行时，每当检测到一个文件变化，一次新的 Compilation 将被创建。Compilation 对象也提供了很多事件回调供插件做扩展。通过 Compilation 也能读取到 Compiler 对象。

好了，看到这里我相信你已经掌握了一个webpack插件的基本开发方式了。这个东西咋说呢，只有自己去多试试，多玩玩上手才能快，下面呆呆也会为大家演示一些稍微复杂一些的插件的开发案例。可以跟着一起来玩玩呀。

唔...看了网上挺多这个fileList.md案例的，要不咱也给整一个？

它的功能点其实很简单：

大家在接收到这个需求的时候，可以先想想要如何去实现：

针对第一点，我认为我们可以传递一个最终生成的文件名进去，例如这样调用：

第二点，因为是在打包完成之前，所以我们可以去compiler 钩子来查查有没有什么可以用的。

咦～这个叫做emit的好像挺符合的：

第三点的话，难道要弄个node的fs？再创建个文件之类的？唔...不用搞的那么复杂，等会让我们看个简单点的方式。

第四点，我们就简单点，例如写入这样的内容就可以了：

由于功能也并不算很复杂，呆呆这里就直接上代码了，然后再来一步一步解析。

还是基于刚刚的案例，让我们继续在plugins文件夹下创建一个新的插件：

plugins/File-list-plugin.js:

代码分析：

好滴，大功告成，让我们赶紧来试试这个新插件吧，修改webpack.config.js的配置：

webpack.config.js:

来执行一下npm run build看看吧：

可以看到，上面👆的案例我们是使用tapAsync来调用钩子函数，这个tapPromise好像还没有玩过，唔...我们看看它是怎样用的。

现在让我们来改下需求，刚刚我们好像看不太出来是异步执行的。现在我们改为1s后才输出资源。

重写一下刚刚的插件：

plugins/File-list-plugin.js:

可以看到它与第一种tapAsync写法的区别了：

大家可以自己写写看看效果，应该是和我们预期的一样的。

另外，tapPromise还允许我们使用async/await的方式，比如这样：

嘻嘻😁，貌似真的也不难。

话不多说，让我们接着来看一个监听的案例。需求如下：

那么首先为了满足第一个条件，我们得设计一条watch的指令，以保证使用npm run watch命令之后，会看到编译过程，但是不会退出命令行，而是实时监控文件。这也很简单，加一条脚本命令就可以了。

呆呆在霖呆呆向你发起了多人学习webpack-构建方式篇(2)中也有说的很详细了。

package.json:

然后想一想我们的插件该如何设计，这时候就要知道我们需要调用哪个钩子函数了。

去官网上看一看，这个watchRun就很符合呀：

针对第三点，监听结束之后，watchClose就可以了：

好的👌，让我们开干吧。在此项目的plugins文件夹下再新建一个叫做Watch-plugin的插件。

先搭一下插件的架子吧：

plugins/Watch-plugin.js:

(额，这个火箭🚀呆呆是用Mac自带的输入法打出来的，其它输入法应该也有吧)

通过上面几个案例的讲解，这段代码大家应该都没有什么疑问了吧。

那么现在的问题就是如何知道哪些文件改变了。其实我们在研究一个新东西的时候，如果没啥思路，不如就在已有的条件上先找一下，比如这里我们就只知道一个compiler，那么我们就可以查找一下它里面的属性，看看有什么是我们能用的吗。

也就是上面的这张图：

可以看到，有一个叫做watchFileSystem的属性应该就是我们想要的监听文件的属性了，打印出来看看？

好滴👌，那就先让我启动这个插件吧，也就是改一下webpack.config.js那里的配置，由于上面几个案例都已经演示过了，呆呆这里就不再累赘，直接跳过讲解这一步了。

直接让我们来npm run watch一下吧，控制台已经输出了它，可是由于我们是需要监听文件的改变，所以虽然控制台输出了watchFileSystem，但是这一次是初始化时打印的，也就是说我们需要改动一下本地的一个资源然后保存再来看看效果。

例如，我随便改动一下src/index.js中的内容然后保存。这时候就触发了监听事件了，让我们来看一下打印的结果：

可以看到watchFileSystem中确实有一个watch属性，而且里面有一个fileWatchers的列表，还有一个mtimes对象。这两个属性引起了我的注意。貌似mtimes对象就是我们想要的了。

它是一个键值对，键名为改动的文件的路径，值为时间。

那么我们就可以直接来获取它了：

好滴，接着：

好滴👌，这样就实现了一个简单的文件监听功能。不过使用mtimes只能获取到简单的文件的路径和修改时间。如果要获取更加详细的信息可以使用compiler.watchFileSystem.watcher.fileWatchers，但是我试了一下这里面的数组是会把node_modules里的改变也算上的，例如这样：

所以如果针对于这道题的话，我们可以写一个正则小小的判断一下，去除node_modules文件夹里的改变，代码如下：

另外呆呆在读 《深入浅出Webpack》的时候，里面也有提到：

默认情况下 Webpack 只会监视入口和其依赖的模块是否发生变化，在有些情况下项目可能需要引入新的文件，例如引入一个 HTML 文件。 由于 JavaScript 文件不会去导入 HTML 文件，Webpack 就不会监听 HTML 文件的变化，编辑 HTML 文件时就不会重新触发新的 Compilation。 为了监听 HTML 文件的变化，我们需要把 HTML 文件加入到依赖列表中，为此可以使用如下代码：

感兴趣的小伙伴可以自己去实验一下，呆呆这里就不做演示了。

再来看个案例，这个插件是用来检测我们有没有使用html-webpack-plugin插件的。

还记得我们前面说的Compiler对象中，包含了 Webpack 环境所有的的配置信息，包含 options，hook，loaders，plugins 这些信息。

那么这样我就可以通过plugins来判断是否使用了html-webpack-plugin了。

由于功能不复杂，呆呆这就直接上代码了：

有需要注意的点⚠️：

配置一下webpack.config.js，来看看效果是可以的：

还记得上面👆的项目我们用到的那个clean-webpack-plugin，现在我们自己来实现一个简易版的clean-webpack-plugin吧，名称就叫Clean-plugin。

一样的，首先还是明确一下我们的需求：

我们需要设计这么一个插件，在每次重新编译之后，都会自动清理掉上一次残余的dist文件夹中的内容，不过需要满足以下需求：

例如我第一次打包之后，生成的dist目录结构是这样的：

然后我修改了一下js文件并重新编译，新的目录结构应该是这样的：

可以看到，如果我们是用chunkhash给输出文件命名的话，只改变js文件，则js文件的文件名会发生变化，而不会影响css文件。

如果对三种hash命名还不清楚的小伙伴，可以花上十分种看下我的这篇文章：霖呆呆的webpack之路-三种hash的区别，里面对三种hash的使用场景以及区别都说的很清楚。

此时，我们就需要将旧的js文件给替换成新的，也就是只删除main.f89e7ffee29ee9dbf0de.js文件。

而如果我们在配置插件的时候加了exclude属性的话，则不需要把这个属性中的文件给删除。例如如果我是这样配置的话：

那么这时候就算你修改了js文件，结果虽然会生成新的js文件，但是也不会把旧的给删除，而是共存：

所以针对于上面这个需求，我们先给自己几个灵魂拷问：

(在这个过程中我们肯定会碰到很多自己不知道的知识点，请不要慌，大家都是有这么一个不会到会的过程)

问题一

在哪个钩子函数中执行，我觉得可以在"done"中，因为我们其中的一个目的就是既能拿到旧的文件夹内容，又能拿到新的。而在这个阶段，表示已经编译完成了，所以是可以拿到最新的资源了。

问题二

获取旧的dist文件夹内的内容。还记得我们的dist文件夹是怎么来的吗？它是在我们webpack.config.js这个文件中配置的output项：

所以很轻松的我们可以通过compiler.options.output.path就拿到这个旧的输出路径了，然后我们需要去读取这个路径文件夹下的所有文件，也就是遍历dist文件夹。

这边我们需要用到一个叫recursive-readdir-sync的东西，稍后我们需要安装它，它的作用就是以递归方式同步读取目录路径的内容。(github地址为：github.com/battlejj/re…)

问题三

获取新生成的所有文件，也就是所有的资源。这点得看"done"回调函数中的参数stats了。如果你把这个参数打印出来看的话会发现它包括了webpack中的很多配置，包括options包括assets等等。而这里我们就是需要获取打包完之后的所有最新资源也就是assets属性。

你以为直接stats.assets获取就完了吗？如果你试图这样去做的话，就会报错了。在webpack中它鼓励你用stats.toJson().assets的方式来获取。这点呆呆也不是很清楚原因，大家可以看一下这里：

www.codota.com/code/javasc…

然后至于options.exclude中的文件名称，这个在插件的构造函数中定义一个options属性就可以拿到了。

合并无重复项我们可以使用lodash.union方法，lodash它是一个高性能的 JavaScript 实用工具库，里面提供了许多的方法来使我们更方便的操作数组、对象、字符串等。而这里的union方法就是能把多个数组合并成一个无重复项的数组，例如🌰：

至于为什么要把这两个数组组合起来呢？那也是为了保证exclude中定义的文件在后面比较的过程中不会被删除。

问题四

将新旧文件列表做对比，得出最终需要删除的文件列表。

唔...其实最难的点应该就是在这里了。因为这里并不是简单的文件名称字符串匹配，它需要涉及到路径问题。

例如，我们前面说到可以通过compiler.options.output.path拿到文件的输出路径，也就是dist的绝对路径，我们命名为outputPath，它可能是长这样的：

而后我们会用一个叫recursive-readdir-sync的东西去处理这个绝对路径，获取里面的所有文件：

这里得到的会是各个文件：

以上得到的列表就是旧的dist文件夹中的所有文件列表。

而后，我们需要得到新生成的文件的列表，也就是stats.toJson().assets.map(file => file.name)和exclude合并后的那个文件列表，我们称为newAssets。但是这里需要注意的就是newAssets中的是各个新生成的文件的名称，也就是这样：

所以我们需要做一些额外的路径转换的处理，再来进行比较。

而如果在路径前缀相同的情况下，我们只需要把recursiveReadSync(outputPath)处理之后的结果做一层过滤，排除掉newAssets里的内容，那么留下来的就是需要删除的文件，也就是unmatchFiles这个数组。

有点绕？让我们来写下伪代码：

在这个匹配的过程中，我们会需要用到一个minimatch的工具库，它很适合用来做这种文件路径的匹配。

github地址可以看这里：github.com/isaacs/mini…

问题五

在上一步中我们会得到需要删除的文件列表，这时候只需要调用一下fs模块中的unlinkSync方法就可以删除了。

例如：

好滴，分析了这么多，是时候动手来写一写了，还是基于之前的那个案例。让我们先来安装一下上面提到的一些模块或者工具：

唔。然后为了能看到之后修改文件有没有删除掉旧的文件这个效果，我们可以来写一些css的样式，然后用MiniCssExtractPlugin这个插件去提取出css代码，这样打包之后就可以放到一个单独的css文件中了。

关于这个插件，不清楚的小伙伴你就理解它为下面这个场景：

我的src下有一个index.js和一个style.css，如果在index.js中引用了style.css的话：

最终的css代码是会被打包进js文件中的，webpack并不会那么智能的把它拆成一个单独的css文件。

所以这时候就可以用MiniCssExtractPlugin这个插件来单独的提前css。(不过这个插件的主要作用还是为了提取公共的css代码哈，在这里我们只是为了将css提取出来)

更多有关MiniCssExtractPlugin的功能可以看我的这篇介绍：霖呆呆的webpack之路-优化篇

好滴，首先让我们来安装它，顺便安装一下另两个loader：

然后在src目录下新建一个style.css文件，并写点样式：

src/style.css:

接着快速来配置一下webpack.config.js:

(这里面有用到一个CleanPlugin的插件，它是我们接下来要创建的文件)

webpack.config.js:

这里有一点前面也提到了，就是关于output.filename的命名和MiniCssExtractPlugin中生成css文件的命名，我们采用contenthash的方式，这样的话，如果我们只改变了js文件的话，那么重新打包之后，就只有js文件的hash会被重新生成，而css不会。这也是为了之后看到效果。

最后，在plugins文件夹下创建我们的Clean-plugin.js吧：

plugins/Clean-plugin.js:

比较难的技术难点在「代码分析」中都已经说明了，这里主要说下：

path.relative()：

path.relative() 方法根据当前工作目录返回 from 到 to 的相对路径。 如果 from 和 to 各自解析到相同的路径（分别调用 path.resolve() 之后），则返回零长度的字符串。

先来看看我们现在的目录结构：

首先执行一遍npm run build，生成如下内容：

然后修改一下src/index.js中的内容，例如添加一行代码，之后再重新执行npm run build：

可以看到，只有改变的index.js被重新删除替换了，而css文件没有。

再来验证一下options.exclude，在webpack.config.js中添加一个插件的参数，就用上一次生成的js的名称吧：

再去修改一下index.js的内容，例如加两个注释，然后执行npm run build，会发现这次旧的js文件并不会被删除，而是会在原来的基础上添加一个新的js文件。这也证明了我们的exclude属性是可用的：

知识无价，支持原创。

参考文章：

你盼世界，我盼望你无bug。这篇文章就介绍到这里。

可算是写完了，希望这6个小小的插件案例能够帮助你对webpack的执行机制有一个更深入的了解，呆呆也会和你一起，一起加油⛽️。

(本章节教材案例GitHub地址: LinDaiDai/webpack-example/tree/webpack-custom-plugin ⚠️：请仔细查看README说明)

喜欢霖呆呆的小伙还希望可以关注霖呆呆的公众号 LinDaiDai 或者扫一扫下面的二维码👇👇👇.

我会不定时的更新一些前端方面的知识内容以及自己的原创文章🎉

你的鼓励就是我持续创作的主要动力 😊.

相关推荐:

《全网最详bpmn.js教材》

《【建议改成】读完这篇你还不懂Babel我给你寄口罩》

《【建议星星】要就来45道Promise面试题一次爽到底(1.1w字用心整理)》

《【建议👍】再来40道this面试题酸爽继续(1.2w字用手整理)》

《【何不三连】比继承家业还要简单的JS继承题-封装篇(牛刀小试)》

《【何不三连】做完这48道题彻底弄懂JS继承(1.7w字含辛整理-返璞归真)》

《【精】从206个console.log()完全弄懂数据类型转换的前世今生(上)》

《霖呆呆的近期面试128题汇总(含超详细答案) | 掘金技术征文》