前端工程化之webpack

mini-css-extract-plugin: 分离样式文件，CSS 提取为独立文件，支持按需加载

clean-webpack-plugin: 目录清理

speed-measure-webpack-plugin: 可以看到每个 Loader 和 Plugin 执行耗时 (整个打包耗时、每个 Plugin 和 Loader 耗时)

webpack-bundle-analyzer: 可视化 Webpack 输出文件的体积 (业务组件、依赖第三方模块)

**5、**是否写过Loader？简单描述一下编写loader的思路？

---

从上面的打包代码我们其实可以知道，Webpack最后打包出来的成果是一份Javascript代码，实际上在Webpack内部默认也只能够处理JS模块代码，在打包过程中，会默认把所有遇到的文件都当作 JavaScript代码进行解析，因此当项目存在非JS类型文件时，我们需要先对其进行必要的转换，才能继续执行打包任务，这也是Loader机制存在的意义。

Loader的配置使用我们应该已经非常的熟悉：

// webpack.config.js

module.exports = {

// …other config

module: {

rules: [

{

test: /^your-regExp$/,

use: [{ loader: “loader-name-A” }, { loader: “loader-name-B” }],

},

],

},

};

/ webpack

通过配置可以看出，针对每个文件类型，loader是支持以数组的形式配置多个的，因此当Webpack在转换该文件类型的时候，会按顺序链式调用每一个loader，前一个loader返回的内容会作为下一个loader的入参。因此loader的开发需要遵循一些规范，比如返回值必须是标准的JS代码字符串，以保证下一个loader能够正常工作，同时在开发上需要严格遵循“单一职责”，只关心loader的输出以及对应的输出。

loader函数中的this上下文由webpack提供，可以通过this对象提供的相关属性，获取当前loader需要的各种信息数据，事实上，这个this指向了一个叫loaderContext的loader-runner特有对象。有兴趣的小伙伴可以自行阅读源码。

module.expor

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：本次编译生