时间戳

首页 > 解决方案 > git子模块与npm包？

git-submodules - git子模块与npm包？

问题描述

我正在使用 git submodule 在项目之间构建和共享组件。该项目尚未投入生产，因此，此时子模块运行良好。

但我担心维护和部署，将其转换为 npm 包是个好主意吗？

标签： git-submodules

解决方案

一个 npm 包将允许跨不同包版本的碎片。另一方面，git 子模块有一点学习曲线，而且工具真的不是那么好。使用 git 子模块，您可以将所有源代码放在一个文件夹中。

如果可能的话，我建议对所有项目使用普通的 monorepo。您可能需要创建构建时间变量（通过 babel 插件/s），您可能需要从后端提供某种“实时配置”。我使用 git 子模块工作了一年，最近我参与了一个使用 npm 共享代码的项目。

我建议对所有共享代码只使用一个git 子模块，而不是几个子模块。我会强烈考虑使用 lerna，并使用你的一个git 子模块来跟踪 lerna 的packages目录。如果团队决定他们不喜欢 git 子模块，您可以轻松地将这个 repo 设为兄弟 git repo，而不是子模块。但是，最重要的是，我建议使用普通的 monorepo。

这是来自 Netflix 的关于 monorepo 的精彩演讲：https ://www.youtube.com/watch?v=VNqmHJtItCs （强烈关注不鼓励 npm 样式的包）

这是谷歌臭名昭著的 monorepo 演讲：https ://www.youtube.com/watch?v=W71BTkUbdqE

这是一个很好的网站，可以帮助您思考良好的开发流程：https : //trunkbaseddevelopment.com/（它主要提倡 monorepo 方法）

如果你正在为不同的客户开发软件（不同的人/公司为类似的项目付钱给你），并且同意它们应该至少 80% 相同，你可能真的很喜欢使用构建标志来帮助开始拆分功能，但我相信您应该非常主动地保持构建标志周围的代码干净，并将重构为可重用的组件/包。给每个客户端某种 build-flags.json。构建标志应该只为特性命名，理论上它们都可以单独切换。有些代码可能是完全为每个项目定制的，在这种情况下，您可能需要考虑使用动态导入，但通常这是我尚未完全克服的痛点，尽管我对此有很多未完善的想法。

如果一个 monorepo 没有发生，我实际上建议在 git 子模块上使用 npm packages+separate repos，假设您可以对包进行良好的语义版本控制。（而且，yalc与标准相反，似乎是将包链接在一起的好工具npm/yarn link）

推荐阅读