手写webpack核心原理，支持typescript的编译和循环依赖问题的解决-Toy模板网

这篇具有很好参考价值的文章主要介绍了手写webpack核心原理，支持typescript的编译和循环依赖问题的解决。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

主要知识点

babel读取代码的import语句
算法：bfs遍历依赖图
为浏览器定义一个require函数的polyfill
算法：用记忆化搜索解决require函数的循环依赖问题

Quick Start

GitHub：https://github.com/Hans774882968/mini-webpack

npm install
npm run bundle
修改index.html依赖的js文件路径（bundle_ts.js），复制到dist文件夹，然后点击打开index.html。

依赖

npm i @babel/parser
npm i @babel/traverse
npm i -D @types/babel__traverse
npm i @babel/core @babel/preset-env
npm i -D @babel/preset-typescript
npm i -D @types/babel__core
npm i -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser
npm i typescript@4.7.4

注意点：

配置eslint后记得重启一下vscode，IDE提示才会生效。
我们的命令在2022-08-27下载了@babel/core7.18.13，对应的ts版本要指定为typescript@4.7.4，否则运行代码会报错。

引言

主要是借鉴参考链接1来实现一个mini-webpack，但在功能上有所超越：

根据入口文件的拓展名，决定用ts或js来编译。
借鉴参考链接3，用“记忆化搜索”解决循环依赖问题。

最大的缺憾是不清楚ts-loader怎么实现，因此这里编译ts的做法是直接判定入口文件的扩展名为.ts，然后用babel实现。

因为参考链接1写得很清晰了，本文仅定位为一个额外补充，不会写得很详细。

初始化项目

npm init
tsc --init

tsconfig.json主要需要设置：

"compilerOptions": {
  "module": "commonjs",
},
"include": [
  "bundle.ts"
]

样就能用tsc命令编译入口文件了。

接下来给package.json加一个命令："bundle": "tsc && node bundle.js"，以后可以直接npm run bundle模拟打包命令了。

目前除了在nodejs代码里用'@babel/preset-typescript'插件以外，不知道怎么快速方便地编译src文件夹下的ts，只好：先手工修改tsconfig.json的include和compilerOptions.module，接着tsc编译，最后还原tsconfig.json。

读取单个文件

getModuleInfo函数主要分析文件的依赖和完成代码转换。

我们需要分析文件的import语句，把依赖的文件（相对路径）转换为相对于项目根目录的路径（下称“绝对路径”）。使用babel相关的库@babel/parser、@babel/traverse和@babel/core完成。
代码转换用@babel/core的transformFromAst方法完成。
我们需要保证生成的js的模块规范是commonjs。对于编译js的情况不需要特别指明，而编译ts的情况需要指明插件：plugins: ['@babel/plugin-transform-modules-commonjs']（参考链接5）。

如何支持typescript的编译

只需要修改@babel/parser的parse方法和@babel/core的transformFromAst方法的调用方式。

需要用到@babel/preset-typescript这个插件。

@babel/preset-typescript没有@babel/preset-env方便，

需要指明filename属性和@babel/plugin-transform-modules-commonjs插件。

遍历依赖图

parseModule函数。因为循环依赖也只不过是形成递归，所以依赖图不局限于DAG，可以是任意有向图。所以只需要用bfs遍历一下（这里更正参考链接1的一处小错误，遍历算法不是递归而是bfs）。

parseModule函数中的for循环for (const { deps } of a)用到了它会继续遍历新加入的元素的特性，不能替换为forEach，是js实现bfs的最简方案。
parseModule函数中的await Promise.all是循环中使用async/await的解决方案（参考链接4）。

parseModule函数的输出为depGraph哈希表，其一个对象的deps属性应该设计为一个哈希表，而非直接设计为数组，下文会解释原因。

生成单个文件

getBundle函数把上面生成的depGraph哈希表扔进代码模板里，这就是打包结果。

为了在浏览器环境给出一个合法的commonjs的polyfill（这里只需要给出require和exports对象），我们在代码模板中定义了自己的require函数。对于一个代码文件来说，其返回值为这个文件的exports对象，其副作用为把整个文件的代码执行了一遍。

`;(function (graph) {
  var exportsInfo = {};
  function require (file) {
    if (exportsInfo[file]) return exportsInfo[file];
    function absRequire (relPath) {
      return require(graph[file].deps[relPath]);
    }
    var exports = {};
    exportsInfo[file] = exports;
    (function (require, exports, code) {
      eval(code);
    })(absRequire, exports, graph[file].code);
    return exports;
  }
  require('${entryPath}');
})(${depGraph});`

值得注意的是，这个require函数实际上是一个递归函数。在eval(code)时可能产生递归。

depGraph哈希表的一个对象的deps属性为什么设计为一个哈希表，而非直接设计为数组？因为待执行的代码中所有的路径都是相对路径，我们需要用graph[file].deps[relPath]这样的方式把它转换为绝对路径。为了完成这个转换，我们还需要设计absRequire函数，它只不过起到一个拦截器的作用。

如何解决循环依赖

此时我们如果打包一个含有循环依赖的入口文件，运行时会栈溢出。以最简单的情况为例：a模块的a函数引用b模块的b函数，b模块的b函数引用a模块的a函数。

怎么解决呢？根据参考链接3，我们可以用“记忆化搜索”的思路，开一个全局变量var exportsInfo = {};。并在exports对象生成以后，立即exportsInfo[file] = exports;。上文案例中，b模块获得的a模块的exports对象的值是空的，但因为对象的浅拷贝特性，对象地址是正确的，在require函数解析a模块完毕后，b模块也就能获得a模块的exports对象的正确值了。