如何将私有GitHub仓库作为Yarn依赖？内部依赖未安装问题

一、为啥直接引用GitHub仓库后，内部依赖没装上？ #

当你用GitHub URL（比如"mycompany-models": "https://github.com/mycompany/mycompany-models#v1.2.0"）作为依赖时，npm的逻辑是只克隆仓库的源码，不会自动帮你跑仓库内部的npm install。毕竟npm包是预打包好的成品，而GitHub仓库是原始源码，npm默认不会额外处理它的依赖树。那些报错的module-resolver、uuid/v4都是mycompany-models自己的依赖，但它们没被安装到该仓库的node_modules里，自然会在导入时提示缺失。

二、加了"install": "npm i"后npm为啥无限挂起？ #

这是典型的循环触发安装脚本搞的鬼：

• 你在主项目执行npm install，npm会先拉取mycompany-models，然后执行它的install脚本npm i；
• 这时候mycompany-models目录下会再跑一次npm install，而npm本身正在处理主项目的依赖树，子依赖里再启动npm进程会打乱整个解析流程，甚至陷入“安装子依赖→触发子依赖的install→再安装子依赖的依赖→无限循环”的死胡同，直接导致进程卡住。

三、必须要转译代码吗？ #

不一定，但得让npm正确处理私有仓库的依赖。给你几个实用方案：

方案1：让npm自动处理私有仓库的依赖

别在私有仓库加install脚本，换个方式让npm帮你装依赖：

• 用私有npm仓库：搭个内部npm仓库（比如Verdaccio），把mycompany-models发布到内部仓库，主项目直接像用普通npm包一样引用，npm会自动处理所有依赖；
• 打包成tgz包：在私有仓库本地执行npm pack生成.tgz包，把这个包传到内部存储（比如公司的文件服务器），然后主项目引用这个tgz的URL，比如"mycompany-models": "https://internal-server.com/mycompany-models-1.2.0.tgz"，这样npm会把它当成普通npm包，自动安装它的依赖。

方案2：手动在主项目处理子依赖

如果不想打包或搭私有仓库，可以在主项目的postinstall脚本里，手动给mycompany-models装依赖：
在主项目的package.json里加：

"scripts": {
  "postinstall": "cd node_modules/mycompany-models && npm install"
}

这样主项目安装完所有依赖后，会自动进入mycompany-models目录跑npm install，完美避开循环问题。

方案3：转译代码（按需选择）

如果你的mycompany-models用了未转译的语法（比如TypeScript、ES6+语法糖），或者依赖了babel插件（比如module-resolver），那确实需要转译。因为主项目的babel配置通常不会包含node_modules里的私有仓库，导致插件无法被识别。这种情况下，你需要在私有仓库里预先转译代码，生成dist目录，然后把package.json里的main字段指向dist/index.js，这样主项目导入的是转译后的成品代码，就不会依赖私有仓库的开发依赖了。

总结一下 #

• 依赖缺失：npm默认不处理GitHub仓库的内部依赖；
• npm挂起：子依赖的install脚本触发了循环安装；
• 转译不是必须的：优先用私有npm仓库或tgz包的方式，或者主项目postinstall手动处理；只有当私有仓库用了未转译语法/专属插件时，才需要转译。

内容的提问来源于stack exchange，提问作者john maccarthy