Webpack面试题(1)

{

“version” : 3,                          // Source Map版本

“file”: “out.js”,                       // 输出文件（可选）

“sourceRoot”: “”,                       // 源文件根目录（可选）

“sources”: [“foo.js”, “bar.js”],        // 源文件列表

“sourcesContent”: [null, null],         // 源内容列表（可选，和源文件列表顺序一致）

“names”: [“src”, “maps”, “are”, “fun”], // mappings使用的符号名称列表

“mappings”: “A,AAAB;;ABCDE;”            // 带有编码映射数据的字符串

}

其中mappings数据有如下规则：

• 生成文件中的一行的每个组用“;”分隔；

• 每一段用“,”分隔；

• 每个段由1、4或5个可变长度字段组成；

有了这份映射文件，我们只需要在我们的压缩代码的最末端加上这句注释，即可让sourceMap生效：

//# sourceURL=/path/to/file.js.map

有了这段注释后，浏览器就会通过sourceURL去获取这份映射文件，通过解释器解析后，实现源码和混淆代码之间的映射。因此sourceMap其实也是一项需要浏览器支持的技术。

如果我们仔细查看webpack打包出来的bundle文件，就可以发现在默认的development开发模式下，每个_webpack_modules__文件模块的代码最末端，都会加上//# sourceURL=webpack://file-path?，从而实现对sourceMap的支持。

sourceMap映射表的生成有一套较为复杂的规则，有兴趣的小伙伴可以看看以下文章，帮助理解soucrMap的原理实现：

Source Map的原理探究

Source Maps under the hood – VLQ, Base64 and Yoda

是否写过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’,

}

]

},

]

}

}

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

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

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);

// or return content;

}

更详细的开发文档可以直接查看官网的 Loader API。

是否写过Plugin？简单描述一下编写plugin的思路？

如果说Loader负责文件转换，那么Plugin便是负责功能扩展。Loader和Plugin作为Webpack的两个重要组成部分，承担着两部分不同的职责。

上文已经说过，webpack基于发布订阅模式，在运行的生命周期中会广播出许多事件，插件通过监听这些事件，就可以在特定的阶段执行自己的插件任务，从而实现自己想要的功能。

既然基于发布订阅模式，那么知道Webpack到底提供了哪些事件钩子供插件开发者使用是非常重要的，上文提到过compiler和compilation是Webpack两个非常核心的对象，其中compiler暴露了和 Webpack整个生命周期相关的钩子（compiler-hooks），而compilation则暴露了与模块和依赖有关的粒度更小的事件钩子（Compilation Hooks）。

Webpack的事件机制基于webpack自己实现的一套Tapable事件流方案（github）

// Tapable的简单使用

const { SyncHook } = require(“tapable”);

class Car {

constructor() {

// 在this.hooks中定义所有的钩子事件

this.hooks = {

accelerate: new SyncHook([“newSpeed”]),

brake: new SyncHook(),

calculateRoutes: new AsyncParallelHook([“source”, “target”, “routesList”])

};

}

/* … */

}

const myCar = new Car();

// 通过调用tap方法即可增加一个消费者，订阅对应的钩子事件了

myCar.hooks.brake.tap(“WarningLampPlugin”, () => warningLamp.on());

Plugin的开发和开发Loader一样，需要遵循一些开发上的规范和原则：

• 插件必须是一个函数或者是一个包含 apply 方法的对象，这样才能访问compiler实例；

• 传给每个插件的 compiler 和 compilation 对象都是同一个引用，若在一个插件中修改了它们身上的属性，会影响后面的插件;

• 异步的事件需要在插件处理完任务时调用回调函数通知 Webpack 进入下一个流程，不然会卡住;

了解了以上这些内容，想要开发一个 Webpack Plugin，其实也并不困难。

class MyPlugin {

apply (compiler) {

// 找到合适的事件钩子，实现自己的插件功能

compiler.hooks.emit.tap(‘MyPlugin’, compilation => {

// compilation: 当前打包构建流程的上下文

console.log(compilation);

// do something…

})

}

}

更详细的开发文档可以直接查看官网的 Plugin API。

最后

本文也是结合一些优秀的文章和webpack本身的源码，大概地说了几个相对重要的概念和流程，其中的实现细节和设计思路还需要结合源码去阅读和慢慢理解。

Webpack作为一款优秀的打包工具，它改变了传统前端的开发模式，是现代化前端开发的基石。这样一个优秀的开源项目有许多优秀的设计思想和理念可以借鉴，我们自然也不应该仅仅停留在API的使用层面，尝试带着问题阅读源码，理解实现的流程和原理，也能让我们学到更多知识，理解得更加深刻，在项目中才能游刃有余的应用。

相关文档链接

Webpack官网
「吐血整理」再来一打Webpack面试题

最后

我可以将最近整理的前端面试题分享出来，其中包含HTML、CSS、JavaScript、服务端与网络、Vue、浏览器、数据结构与算法等等，还在持续整理更新中，希望大家都能找到心仪的工作。

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

篇幅有限，仅展示部分截图：