其作用是使用 memory-fs 对象替换掉 compiler 的文件系统对象，让 webpack 编译后的文件输出到内存中。
fileSystem = new MemoryFileSystem(); // eslint-disable-next-line no-param-reassign compiler.outputFileSystem = fileSystem;
通过以上 3 个部分的执行，我们以 watch mode 的方式启动了 webpack，一旦监测的文件变更，便会重新进行编译打包，同时我们又将文件的存储方法改为了内存存储，提高了文件的存储读取效率。最后，我们只需要返回 express 的中间件就可以了，而中间件则是调用 middleware(context) 函数得到的。下面，我们来看看 middleware 是如何实现的。
middleware.js
此文件返回的是一个 express 中间件函数的包装函数，其核心处理逻辑主要针对 request 请求，根据各种条件判断，最终返回对应的文件内容：
function goNext() { if (!context.options.serverSideRender) { return next(); } return new Promise((resolve) => { ready( context, () => { // eslint-disable-next-line no-param-reassign res.locals.webpackStats = context.webpackStats; // eslint-disable-next-line no-param-reassign res.locals.fs = context.fs; resolve(next()); }, req ); }); }
首先，middleware 中定义了一个 goNext() 方法，该方法判断是否是服务端渲染。如果是，则调用 ready() 方法（此方法即为 ready.js 文件，作用为根据 context.state 状态判断直接执行回调还是将回调存储 callbacks 队列中）。如果不是，则直接调用 next() 方法，流转至下一个 express 中间件。
const acceptedMethods = context.options.methods || ['GET', 'HEAD']; if (acceptedMethods.indexOf(req.method) === -1) { return goNext(); }
接着，判断 HTTP 协议的请求的类型，若请求不包含于配置中（默认 GET、HEAD 请求），则直接调用 goNext() 方法处理请求：
let filename = getFilenameFromUrl( context.options.publicPath, context.compiler, req.url ); if (filename === false) { return goNext(); }
然后，根据请求的 req.url 地址，在 compiler 的内存文件系统中查找对应的文件，若查找不到，则直接调用 goNext() 方法处理请求：
return new Promise((resolve) => { // eslint-disable-next-line consistent-return function processRequest() { ... } ... ready(context, processRequest, req); });
最后，中间件返回一个 Promise 实例，而在实例中，先是定义一个 processRequest 方法，此方法的作用是根据上文中找到的 filename 路径获取到对应的文件内容，并构造 response 对象返回，随后调用 ready(context, processRequest, req) 函数，去执行 processRequest 方法。这里我们着重看下 ready 方法的内容：
if (context.state) { return fn(context.webpackStats); } context.log.info(`wait until bundle finished: ${req.url || fn.name}`); context.callbacks.push(fn);
非常简单的方法，判断 context.state 的状态，将直接执行回调函数 fn，或在 context.callbacks 中添加回调函数 fn。这也解释了上文提到的另一个特性 “在编译期间，停止提供旧版的 bundle 并且将请求延迟到最新的编译结果完成之后”。若 webpack 还处于编译状态，context.state 会被设置为 false，所以当用户发起请求时，并不会直接返回对应的文件内容，而是会将回调函数 processRequest 添加至 context.callbacks 中，而上文中我们说到在 compile.hooks.done 上注册了回调函数 done，等编译完成之后，将会执行这个函数，并循环调用 context.callbacks。
总结
源码的阅读是一个非常枯燥的过程，但是它的收益也是巨大的。上文的源码解读主要分析的是 webpack-dev-middleware 它是如何实现它所拥有的特性、如何处理用户的请求等主要功能点，未包括其他分支逻辑处理、容错。还需读者在这篇文章基础之上，再去阅读详细的源码，望这篇文章能对你的阅读过程起到一定的帮助作用。
到此这篇关于webpack-dev-middleware 源码解读的文章就介绍到这了,更多相关webpack-dev-middleware 源码解读内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
您可能感兴趣的文章: