CommonJS模块采…模块循环依赖问题

在项目比较小的时候可能不怎么会遇到这个问题但项目一旦有一定的体量后就可能会遇到了。

CommonJS模块采用深度优先遍历并且是加载时执行即脚本代码在require时就全部执行。

一旦出现某个模块被“循环加载”就只输出已经执行的部分没有执行的部分不会输出。

举例子

执行a.js为moduleA添加属性,发现第一行导入b.js模块a还没执行完执行b.js

require(./b.js);

执行b.js发现导入a.js此时moduleCache有moduleA,不会重复执行模块a的代码会直接用moduleCache中模块a已经导出的内容。

const

moduleCache.moduleA因为此时模块a的内容还未完全执行完所以解构的变量a是undefined还不是function所以报错。

webpack打包结果分析

(__unused_webpack_module,__webpack_exports__,__webpack_require__)

{__webpack_require__.r(__webpack_exports__);__webpack_require__.d(__webpack_exports__,

{A:

_b_js__WEBPACK_IMPORTED_MODULE_0__

__webpack_require__(./src/b.js);var

function

(__unused_webpack_module,__webpack_exports__,__webpack_require__)

{__webpack_require__.r(__webpack_exports__);var

_a_js__WEBPACK_IMPORTED_MODULE_0__

__webpack_require__(./src/a.js);(0,

_a_js__WEBPACK_IMPORTED_MODULE_0__.A)();},};var

{};function

__webpack_module_cache__[moduleId];if

(cachedModule

(__webpack_module_cache__[moduleId]

{exports:

{},});__webpack_modules__[moduleId](module,

module.exports,

(__webpack_require__.o(definition,

key)

!__webpack_require__.o(exports,

key))

{Object.defineProperty(exports,

key,

definition[key],});}}};})();(()

(obj,

Object.prototype.hasOwnProperty.call(obj,

prop);})();(()

{Object.defineProperty(exports,

Symbol.toStringTag,

Module,});}Object.defineProperty(exports,

__esModule,

{};__webpack_require__.r(__webpack_exports__);var

_a__WEBPACK_IMPORTED_MODULE_0__

__webpack_require__(./src/a.js);

var

(__unused_webpack_module,__webpack_exports__,__webpack_require__)

{__webpack_require__.r(__webpack_exports__);

标记模块为ES模块__webpack_require__.d(__webpack_exports__,

{A:

_b_js__WEBPACK_IMPORTED_MODULE_0__

__webpack_require__(./src/b.js);var

function

(__unused_webpack_module,__webpack_exports__,__webpack_require__)

{__webpack_require__.r(__webpack_exports__);var

_a_js__WEBPACK_IMPORTED_MODULE_0__

__webpack_require__(./src/a.js);(0,

_a_js__WEBPACK_IMPORTED_MODULE_0__.A)();},};webpack自定义require导入函数

function

__webpack_module_cache__[moduleId];if

(cachedModule

(__webpack_module_cache__[moduleId]

{exports:

{},});__webpack_modules__[moduleId](module,

module.exports,

查看缓存是否有模块导出结果如果模块执行过了返回模块导出结果在执行模块代码之前先创建模块导出对象module.exports将模块导出对象传入执行模块代码

定义模块导出属性

将模块导出对象标记ES模块如果模块有导出内容会将这些内容定义到模块导出对象

代码执行流程

__webpack_require__.r(__webpack_exports__);

__webpack_require__.d(__webpack_exports__,

{A:

_b_js__WEBPACK_IMPORTED_MODULE_0__

__webpack_require__(./src/b.js);

执行到这里

定义了一个A属性A属性是一个存取器属性有gettergetter就是返回真正导出的A。

执行b模块

__webpack_require__.r(__webpack_exports__);

var

_a_js__WEBPACK_IMPORTED_MODULE_0__

__webpack_require__(./src/a.js);(0,

_a_js__WEBPACK_IMPORTED_MODULE_0__.A)();跟Commonjs的问题一样模块A还没有执行完A还没有赋值所以A这里是undefined不能作为函数调用。

打包结果中模块代码执行前会去先定义导出属性为属性设置一个getter因此在代码模块执行前这些导出属性就已经在导出对象中有getter。

这里因为配置babel打包结果会把const转成var所以变量声明提升了如果是const就会变成变量在声明前使用。

项目会形成循环依赖实际开发中很难避免有可能引入了某个模块就会导致形成依赖链路。

形成循环依赖链路并不一定会报错但是在执行到对应模块时之前模块因为导入其他包模块代码还没完全执行完内容还没完全导出就有可能导致报错。

其实导致报错还好因为可以提前在本地就感知到处理但是如果你只是定义了一个变量那么这个变量可能是在你还没有赋值的时候就引用了所以其实模块导出的变量并不是一定可信的。

其实在遇到函数调用报错时可以通过把一些函数表达式改成函数声明就好因为打包结果模块的执行其实是执行一个函数在执行前会有函数声明提升但尽量不要用这种规范来处理因为很可能会遇到更多坑。

其实有模块循环依赖后还报错本身就是这条依赖链路有问题应该找到不合理的地方解决而不是去规避。

用函数声明解决一些问题反倒会留下一些坑可能某些环境的值原本因为循环依赖导致引用时是undefined,但是碰巧你用函数声明避免了一些报错导致埋了一个坑。

有一些工具可以分析项目中的循环链路eslint也有相应的配置。

至于如何找到循环依赖的不合理地方就凭经验吧这里就不展开了毕竟是个人观点。