1.一个关于webpack 自动use strict引起的码分有趣的业务bug以及背后原理
2.Webpack进阶less-loader、css-loader、码分style-loader源码解析
3.源码细读-深入了解terser-webpack-plugin的码分实现
4.webpack打包原理 ? 看完这篇你就懂了 !
5.webpack 4 源码主流程分析（十一）：文件的生成
6.探究webpack代码热更新原理

一个关于webpack 自动use strict引起的有趣的业务bug以及背后原理

       Webpack自动use strict引起的业务bug分析

       在处理业务bug的过程中，我发现它不仅提供了锻炼技巧的码分机会，还揭示了一些隐藏的码分知识点。

       问题起因于公司管理后台，码分cocos围棋对战源码一个基于webpack多页面应用的码分项目，其中部分文件夹使用了webpack的码分特殊处理，而其他未处理的码分文件夹则仅简单地使用babel进行es5转换。当某个需求需要迁移至已处理的码分文件夹时，问题出现了。码分

       问题代码中，码分一个函数没有声明就直接被使用，码分导致了"params is 码分not defined"的错误。这是码分因为引入了严格模式，严格模式下未声明就使用会导致编译错误。

       解决方法简单，只需为变量声明即可。然而，问题的关键在于严格模式的来源。虽然代码本身并未主动引入，但webpack的打包过程可能在无意中引入了。

       在webpack打包产物对比中，我们发现迁移后引入了use strict，这成为问题的根源。进一步的代码分析发现，use strict的出现与import的使用有关，因为webpack会将import转换为浏览器兼容的形式，并将其依赖放在头部执行。八浪公式源码

       总结来说，问题在于在使用import时，webpack遵循ES6模块的严格模式规范，而es module本身已经是严格模式。因此，webpack会自动添加use strict以适应es module。通过追踪Webpack源码，我们找到了use strict插入的确切位置，这解决了问题的原因。

Webpack进阶less-loader、css-loader、style-loader源码解析

       Webpack进阶学习中，Loader的运用是关键环节。在深入理解Loader基础后，本文将解析less-loader、css-loader和style-loader的内部工作原理。

       less-loader是专为处理Less样式文件设计的，它将Less代码转换为浏览器能识别的CSS。以less文件为例，其工作原理是调用less库的功能，将扩展了CSS特性的Less代码转化为CSS，如变量、Mixin和函数等。

       css-loader的功能则更为复杂，它不仅处理@import和url语句，还支持css-modules，将样式文件内容合并并作为JavaScript模块输出。以多个样式文件（如a.css、快鲸源码商城b.css和c.css）为例，css-loader会将它们合并成一个JavaScript模块，输出包含所有样式内容的字符串。

       style-loader的作用在于将css-loader转化后的CSS样式代码插入到DOM中。理论上，我们可能期望直接在JavaScript中插入CSS代码，但css-loader返回的是模块化的代码，不能直接放入style标签。style-loader的实现通过一种巧妙的方式，将这些模块代码适当地包装，确保样式能正确插入到文档中。

       style-loader的设计思路独特，其内部逻辑涉及Loader调用链、执行顺序和模块化输出等多个层面，理解style-loader的运作机制，对于深化对Webpack和Loader的理解至关重要。深入研究这些Loader的源码，无疑能提升你对Webpack进阶应用的掌握程度。

源码细读-深入了解terser-webpack-plugin的实现

       terser-webpack-plugin 是一个基于 webpack 的插件，它利用 terser 库对 JavaScript 代码进行压缩和混淆。其核心功能在于通过在 webpack 的运行时钩子 optimizeChunkAssets 中注册，实现了代码优化过程。在 apply 函数中，它获取 compilation 实例，并通过 tapPromise 注册一个异步任务，当 webpack 执行优化阶段时，每个 chunk 会触发这个任务，执行 minify 函数进行压缩处理。mpc控制算法源码

       optimise 函数是实际的任务处理入口，它负责具体的优化流程。函数内部，scheduleTask 负责并行处理，如果开启 parallel 模式，会利用jest-worker提供的线程池进行并发工作，线程池管理复杂，根据 node 版本不同采用 worker_threads 或 child_process。minify 函数则是压缩和混淆代码的核心操作，它直接使用 terser 库完成任务。

       总的来说，terser-webpack-plugin 的优化流程包括在 webpack 的优化阶段对代码进行压缩，使用 Jest 的 worker 线程池进行并行处理，以及通过 terser 库的实际压缩操作。理解这些核心环节，可以帮助开发者更深入地掌握该插件的使用和工作原理。

webpack打包原理 ? 看完这篇你就懂了 !

       深入浅出 webpack

       webpack 是一个现代 JavaScript 应用程序的静态模块打包器，其本质是对模块进行递归构建依赖关系图，然后打包成一个或多个 bundle。

       理解 webpack 的工作流程，像是理解一条生产线，每一步都有其职责，依赖于前一步骤的结果。插件则像是生产线中的功能模块，根据特定时机对资源进行处理。

       webpack 通过 Tapable 组织整个生产流程，它在运行中广播事件，插件只需监听感兴趣的交易模型指标源码事件，即可加入流程，改变整个系统。事件流机制确保了插件的有序性，提高了系统的扩展性。

       webpack 的核心概念包括：入口起点（Entry），定义了构建开始的模块；输出（Output），指定生成的 bundle 存储位置；模块（Module），一切皆模块，所有资源被转换为模块；代码块（Chunk），多个模块组合用于代码优化；loader，处理非 JavaScript 文件，将所有类型转换为可引用的模块；插件，执行更广泛任务。

       理解 webpack 的构建流程，从入口文件开始，遍历依赖关系，转换为浏览器可执行代码，并生成最终的 bundle。在实践过程中，定义 Compiler 类，使用 babel 解析源代码，遍历 AST 抽象语法树，找出依赖模块，转换为可执行代码，并构建依赖关系图，重写 require 函数以输出 bundle。

       完成 webpack 的理解，需要通过实践，例如构建一个简易版本的 webpack。从定义 Compiler 类开始，解析入口文件，使用 babel 解析内部语法，找出依赖模块，将 AST 转换为代码，递归解析所有依赖项，构建依赖关系图，重写 require 函数以输出 bundle。

       通过实际操作，可以深入理解 webpack 的 bundle 实现过程，从入口文件执行开始，利用 eval 执行代码，处理依赖引用，生成最终的 bundle。通过这个实践过程，可以全面掌握 webpack 的工作原理和使用方法。

webpack 4 源码主流程分析（十一）：文件的生成

       本文深入分析了 Webpack 4 中文件生成的具体流程。在资源写入文件阶段，通过一系列优化和处理，最终返回到 Compiler.js 的 compile 方法，其中 Compiler 的属性 _lastCompilationFileDependencies 和 _lastCompilationContextDependencies 被赋予了 fileDependencies 和 contextDependencies。紧随其后的是创建目标文件夹的过程，该操作通过 outputPath 属性配置，结合 mkdirp 函数完成。

       在创建目标文件并写入阶段，通过 asyncLib.forEachLimit 方法并行处理每个文件资源，实现路径拼接、源码转换为 buffer，最后写入真实路径的文件。对于不同类型的 source 实例，如 CachedSource、ConcatSource 和 ReplaceSource，其处理逻辑各不相同，但最终目标都是获取替换后的字符串并合并返回 resultStr。所有文件创建写入完成后，执行回调，触发Compiler.afterEmit:hooks，进一步设置 stats 并打印构建信息。

       至此，构建流程全部结束。通过本文的分析，我们可以更直观地了解 Webpack 4 中文件生成的具体实现细节，为深入理解 Webpack 的工作原理和优化提供理论支持。本章小结，下章将解析打包后的文件，敬请期待。

探究webpack代码热更新原理

       一、前备知识

       1.HMR-HotModuleReplacement热模块替换发生代码改动时，保持当前页面状态的同时，局部更新修改模块

       2.piler?=?webpack(config);?//?这里的server是全局变量?server?=?new?Server(compiler,?options,?log);?if?(options.socket)?{ ?server.listen(options.socket,?options.host,?(err)?=>?{ })?}?else?{ ?server.listen(options.port,?options.host,?(err)?=>?{ })?}?}

       深入核心，了解如何通过compiler初始化服务器server对象，并且调用listen方法

//?webpack-dev-server/lib/Server.js?class?Server?{ ?constructor(compiler,?options?=?{ },?_log)?{ ?//?保存webpack实例?this.compiler?=?compiler;?//?保存用户的配置参数?this.options?=?options;?this.heartbeatInterval?=?;?//?socketServer参数?this.socketServerImplementation?=?getSocketServerImplementation(this.options);?this.sockets?=?[];?//?设置文件监听的目录范围?this.contentBaseWatchers?=?[];?//?开启代码热更新的必备参数?this.hot?=?this.options.hot?||?this.options.hotOnly;?//?文件监听配置?this.watchOptions?=?options.watchOptions?||?{ };?this.setupHooks();?this.setupApp();?this.setupDevMiddleware();?this.createServer();?}?//?使用文件编译结束的钩子?setupHooks()?{ ?const?addHooks?=?(compiler)?=>?{ ?done.tap('webpack-dev-server',?(stats)?=>?{ ?//?服务端编译结束通过websocket告知客户端，以及传递当前的hash值和ok?this._sendStats(this.sockets,?this.getStats(stats));?this._stats?=?stats;?})?}?if?(this.compiler.compilers)?{ ?this.compiler.compilers.forEach(addHooks);?}?else?{ ?addHooks(this.compiler);?}?}?_sendStats(sockets,?stats,?force)?{ ?this.sockWrite(sockets,?'hash',?stats.hash);?this.sockWrite(sockets,?'ok');?}?//?利用express初始化一个服务器，用于静态资源的路由?setupApp()?{ ?this.app?=?new?express();?}?//?配置express搭建后的服务器，确认使用的协议?createServer()?{ ?//?如果使用的协议是piler,?Object.assign({ },?this.options,?{ ?logLevel:?this.log.options.level?})?)?}//?创建websocket服务器，用于下发模块更新的通知到客户端?createSocketServer()?{ ?const?SocketServerImplementation?=?this.socketServerImplementation;?this.socketServer?=?new?SocketServerImplementation(this);?this.socketServer.onConnection((connection,?headers)?=>?{ })?}?//?监听对应的端口开启静态资源路由，同时部署另一个websocket服务器?listen(port,?hostname,?fn)?{ ?return?this.listeningApp.listen(port,?hostname,?(err)?=>?{ ?this.createSocketServer();?}?}?}?//?添加两个打包入口模块，利用webpack将相关代码注入到bundle.js中，用于客户端开启websokct以及处理热模块替换?Server.addDevServerEntrypoints?=?require('./utils/addEntries');?module.exports?=?Server;

       到这里webpack的HMR在node层做的处理基本完成了，这部分同样是让服务端拥有静态资源路由以及主动下发代码更新通知到客户端的能力，下面看一下如何实现客户端接收websocket通知后主动拉取更新后的服务端代码，并且替换执行新的模块代码

       webpack客户端的代码肯定不会让开发人员自己去实现，不然就会出现千奇百怪的问题。这部分代码处理被黑盒处理，隐藏在了Server.addDevServerEntrypoints方法内，悄悄得在webpack带包过程中添加entry注入这部分代码处理

       巧妙地划分客户端能力到两个模块中

//?webpack-dev-server/utils/addEntries.js?function?addEntries(config,?options,?server)?{ ?const?domain?=?createDomain(options,?app);?const?sockHost?=?options.sockHost`&sockHost=${ options.sockHost}`?:?'';?const?sockPath?=?options.sockPath`&sockPath=${ options.sockPath}`?:?'';?const?sockPort?=?options.sockPort`&sockPort=${ options.sockPort}`?:?'';?//?引入搭建websocket客户端代码块module?const?clientEntry?=?`${ require.resolve(?'../../client/'?)}?${ domain}${ sockHost}${ sockPath}${ sockPort}`;?//?处理客户端从服务端获取新模块并且替换执行的代码块module?let?hotEntry;?if?(options.hotOnly)?{ ?hotEntry?=?require.resolve('webpack/hot/only-dev-server');?}?else?if?(options.hot)?{ ?hotEntry?=?require.resolve('webpack/hot/dev-server');?}?}?module.exports?=?addEntries;

       从这里可以看出来，客户端需要的两个能力被划分到了两个代码模块中，一个是搭建websocket客户端，一个是处理客户端的代码模块更新和替换

       搭建websocket客户端

//?webpack-dev-server/client/index.js?var?socket?=?require('./socket');?var?sendMessage?=?require('./utils/sendMessage');?var?createSocketUrl?=?require('./utils/createSocketUrl');?var?reloadApp?=?require('./utils/reloadApp');?var?socketUrl?=?createSocketUrl(__resourceQuery);?var?onSocketMessage?=?{ ?//?接收websocket服务端返回的最新hash值?hash:?function?hash(_hash)?{ ?status.currentHash?=?_hash;?}?ok:?function?ok()?{ ?sendMessage('Ok');?reloadApp(options,?status);?}?}?socket(socketUrl,?onSocketMessage);

       当客户端收到服务端返回的ok消息推送时，会调用reloadApp，这里看一下具体是怎么处理的

//?webpack-dev-server/client/utils/reloadApp.js?function?reloadApp(_ref,?_ref2)?{ ?if?(hot)?{ ?log.info('[WDS]?App?hot?update...');?var?hotEmitter?=?require('webpack/hot/emitter');?hotEmitter.emit('webpackHotUpdate',?currentHash);?//?如果当前宿主是浏览器环境，则触发webpackHotUpdate消息推送?if?(typeof?self?!==?'undefined'?&&?self.window)?{ ?self.postMessage("webpackHotUpdate".concat(currentHash),?'*');?}?}?}?module.exports?=?reloadApp;

       所以调用this.postMessage("webpackHotUpdate".concat(currentHash),'*')

       有发送就会有接收，找一下对应的回调处理，而处理这部分的代码被划分到了hot模块中，根据hash获取新的代码模块并进行替换执行

       处理客户端的代码模块更新和替换

//?webpack/hot/dev-server.js?if?(module.hot)?{ ?var?lastHash;?var?check?=?function?check()?{ ?module.hot?.check(true)?.then(function(updatedModules)?{ ?//?容错，如果不存在待更新的模块，直接刷新页面?if?(!updatedModules)?{ ?log("warning",?"[HMR]?Cannot?find?update.?Need?to?do?a?full?reload!");?log(?"warning",?"[HMR]?(Probably?because?of?restarting?the?webpack-dev-server)"?);?window.location.reload();?return;?}?}?.catch(function(err)?{ ?window.location.reload();?}?}?hotEmitter.on("webpackHotUpdate",?function(currentHash)?{ ?lastHash?=?currentHash;?if?(!upToDate()?&&?module.hot.status()?===?"idle")?{ ?log("info",?"[HMR]?Checking?for?updates?on?the?server...");?//?调用check方法拉取更新后的模块代码并进行处理?check();?}?});?}

       这里的module.hot.check方法，其实是另一位隐藏的大佬进行的方法注入

       HotModuleReplacementPlugin

       由于涉及到另一个插件的解析，放到后面去扩展。感兴趣的读者可以去webpack/lib/hotModuleReplacement.js阅读源码。

       这里重点介绍针对module.hot.check都注入了怎样的代码

//?webpack/lib/web/JsonpMainTemplate.runtime.jsfunction?hotCreateModule(moduleId)?{ ?var?hot?=?{ ?check:?hotCheck?}function?hotCheck(apply)?{ ?hotSetStatus("check");?return?hotDownloadManifest(hotRequestTimeout).then(function(update)?{ ?hotAvailableFilesMap?=?update.c;?hotUpdateNewHash?=?update.h;?hotSetStatus("prepare");})?}?function?hotDownloadManifest(requestTimeout)?{ ?requestTimeout?=?requestTimeout?||?;?return?new?Promise(function(resolve,?reject)?{ ?var?request?=?new?XMLHttpRequest();?var?requestPath?=?__webpack_require__.p?+?""?+?hotCurrentHash?+?".hot-update.json";?request.open("GET",?requestPath,?true);?request.timeout?=?requestTimeout;?request.send(null);?request.onreadystatechange?=?function()?{ ?var?update?=?JSON.parse(request.responseText);?resolve(update);?}?}?}

       这里之所以使用JSONP的方式获取新的模块代码，是因为JSONP获取的代码可以直接执行，而hash.hot-update.js代码里有个webpackHotUpdate函数调用，最后重点看一下这个函数是如何处理代码模块替换和执行的

//?webpack/lib/HotModuleReplacement.runtime.js?window["webpackHotUpdate"]?=?function?(chunkId,?moreModules)?{ ?hotAddUpdateChunk(chunkId,?moreModules);?}；?function?hotAddUpdateChunk(chunkId,?moreModules)?{ ?//?更新的模块moreModules赋值给全局全量hotUpdate?for?(var?moduleId?in?moreModules)?{ ?if?(Object.prototype.hasOwnProperty.call(moreModules,?moduleId))?{ ?hotUpdate[moduleId]?=?moreModules[moduleId];?}?}?//?调

一文看懂 webpack 的所有 source map ！🤔

       深入理解Webpack的各类source map

       在前端开发中，source map经常让人感到困惑，尤其在Webpack提供的众多source选项中。本文将逐一探讨它们的不同之处。

       source map，就像是编译后的代码与原始源代码之间的导航图，有助于在生产环境中追踪和修复错误。当代码编译后，失去可读性，source map的作用就是通过编译后的代码找到对应的源代码位置，帮助开发者快速定位问题。

       在webpack配置中，devtool属性控制source map的生成形式。它支持多种类型，尽管名称多样，但核心机制相似。理解几个关键术语是关键：eval、source-map、inline-source-map、nosources-source-map、hidden-source-map、cheap-source-map和cheap-module-source-map。

       以eval为例，它不生成独立的.map文件，而是将映射信息内置于eval函数中，虽然在开发环境中能提供一些帮助，但在生产环境中由于调试体验差而不可取。而source-map则是最标准的形式，生成单独的.map文件，错误信息定位准确，能查看源码。

       尝试在项目中故意引入错误，可以看到不同source map类型下的报错信息差异。eval-source-map提供基本的错误定位，但列号可能不准确。而inline-source-map和nosources-source-map则展示了源码信息的完整性和缺失。hidden-source-map和cheap-source-map虽然有映射，但信息可能模糊或处理过。而cheap-module-source-map则定位正确，但无法定位到具体列。

       总结来说，理解source map的关键在于理解每个选项背后的含义，如何根据项目需求选择合适的配置。希望这篇文章能帮助你清晰地认识Webpack的source map功能。