假设您有此设置:
root
project1
package.json { "version" : "0.0.1" }
project2
package.json { "version" : "0.0.1",
"dependencies" : { "project1" : "^0.0.1"] }
main
package.json ("dependencies" : { "project1" : "^0.0.1" }
Project1,project2,projectXxxx ......和main必须一起改变。他们可能所有一直更改(它几乎不可能在main中实现任何东西而不依赖于project1,project2等......这是不很少更改库的场景。)
你如何避免这两个陷阱:
您可以使用' npm链接'本地。但是,每个开发人员都必须手动调用' npm link'在所有项目中,按正确的顺序。 新开发人员(或刚签出新开发分支的人)的工作流程为:
让它超过两个项目,它的疯狂。
tl; Dr Don不使用安装。使用.gyp文件进行编译,以及 预先发布其他任何内容。
您几乎不必明确设置预安装或安装 脚本。如果你这样做,请考虑是否有另一个 选项。
安装或预安装脚本的唯一有效用途是编译 必须在目标架构上完成。
或者,每次更改内容时,您都可以将每个模块发布到私有存储库。工作流程(据我所知):
如您所见,这一切都不可接受。
那么你会改变什么来获得合理的工作流程?
你把所有东西放在同一个项目中吗? (遗憾的是,在我的情况下这是不可接受的,因为其他地方的其他项目也需要project1。)
我错过了&n; npm xxxxx'执行此操作的命令?
由于
答案 0 :(得分:1)
听起来通常是轻微的麻烦正在成为您的主要问题,因为您的项目设计没有实现足够宽松的耦合。从根本上说,我认为你有一种代码味道,在某种形式或其他主要方面,project1和project2实际上仍然是一个单一的应用程序,应该是一个单独的模块,或者project1没有被正确抽象,所以它可以拆分并由MAIN2。继续重构它,在某些时候你会有一个灯泡时刻,并找到一个更清洁的组织。
然而,与此同时,我确实有一个建议,应该有所帮助。当我处于类似的情况时,我们将所有帮助程序模块作为单独的项目保存在它们自己的私有github存储库中,当一个新的开发人员克隆main时,我们有一个shell脚本来设置以下结构,其中的关键是{{ 1}}是一个高于正常的目录:
node_modules
这允许两种开发模式:
ROOT
main
project1
project2
node_modules
project1 (symlink to ../project1)
project2 {symlink to ../project2)
会让您进入正常模式并按正常方式安装兄弟项目cd main && npm install
ROOT/main/node_modules/project1
main/package.json
会让您进入同步开发模式
cd main && rm -rf node_modules/project[12]
中的代码main
时,它会从本地require("project1")
符号链接中找到它,您可以快速编辑任何项目中的代码。无需修改版本号,推送提交或npm安装任何内容来测试更改。ROOT/node_modules/project1
会让您恢复正常模式由于使用符号链接,这在Windows,FYI上可能无法正常工作。
您可以在cd main && npm install
中编写一个shell脚本,开发人员可以在第一次克隆main
repo时运行该脚本以设置此结构。