在通过gulp-submodule注入依赖项的模块上运行gulp任务，通过gulp-submodule依次拥有自己的依赖项，失败

标题可能听起来有点模糊，但这里是一个错误的例子。 假设我们有三个模块ModuleA ， ModuleB和ModuleC ，所以ModuleA依赖于ModuleB，而ModuleB依赖于ModuleC 。 当我们需要针对ModuleA运行一个任务时，我们通常还需要针对它的依赖运行一些任务 – ModuleB和ModuleC ，这里是gulp -submodule的作用。 Gulp子模块让我们定义依赖模块及其依赖项的任务之间的依赖关系，以便依赖模块的任务触发其依赖关系的适当任务。

如果我们有一个扁平的结构，这个工作相当好，即SomeModule依赖于一堆没有自己的依赖的模块。 然而，一旦这些依赖关系有其自身的依赖关系，整个生态系统就会打破一个晦涩难懂的错误信息，说明吞没了某个任务。

这里是演示代码。 要在本地环境中进行testing，必须至less将gulp安装为全局程序包，并将gulp和gulp子模块作为本地程序包安装。

模块a.gulpfile.js

const gulp = require("gulp"); require("gulp-submodule")(gulp); gulp.submodule("module-b", {filepath: "module-b.gulpfile.js"}); gulp.task("default", ["module-b:default"], () => { console.log("Running task 'default' for module 'module-a'..."); }); 

模块b.gulpfile.js

 const gulp = require("gulp"); require("gulp-submodule")(gulp); gulp.submodule("module-c", {filepath: "module-c.gulpfile.js"}); gulp.task("default", ["module-c:default"], () => { console.log("Running task 'default' for module 'module-b'..."); }); 

模块c.gulpfile.js

 const gulp = require("gulp"); gulp.task("default", [], () => { console.log("Running task 'default' for module 'module-c'..."); }); 

一旦你在module-a.gulpfile.js上运行任务'default'，你会得到类似如下的输出：

gulp –gulpfile模块-a.gulpfile.js
[07:15:27]使用gulpfile模块-a.gulpfile.js
[07:15:27]任务'module-b：module-c：default'不在你的gulpfile中
[07:15:27]请检查文档的适当的gulpfile格式

可能会注意到，gulp正在寻找一个名为“module-b：module-c：default”的特定任务，尽pipe在任何项目文件中都没有定义或引用具有该名称的任务。

Answer 1

这个奇怪的不存在的任务来自于gulp-submodule处理模块和任务之间的依赖关系。 简而言之，它会执行以下操作：

1. 首先，在这个调用中， gulp.submodule("module-b", {filepath: "module-b.gulpfile.js"}) -submodule临时replace原始的gulp.task ，并将指定的gulp文件作为模块加载。
2. 加载gulp文件时，获取gulp的修改实例，其中task方法通过在模块名称和分隔符（默认情况下为“：”）之前修改作为其参数提交的任务的名称。
3. 后来，当gulp运行模块“module-a”的任务“default”时，它遇到了一个我们称之为“module-b：default”的依赖关系，这正是为模块的task默认构造的特殊名称步骤2中的“module-b”。

如果使用多个级别的依赖关系层次结构，这个直接的逻辑就会中断，因为调用gulp.submodule("module-c", {filepath: "module-c.gulpfile.js"})一个gulp.task第二次被gulp.task -submodule包装，因此模块'module-c'的任务'default'的名字被前置两遍：先用'module-c'然后用'module-b'。

为了快速解决这个问题，我已经提交了一个快捷方式修补程序给我们的原始子模块： 5864ae5 （ gulp -submodule ）。 这只是一个快速的解决scheme，绝对不是最好的，但它为我做了伎俩。 我会更新这个答案，我是否会对这个问题提出一个更坚实的解决scheme。