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

Question

我正在使用 git submodule 在项目之间构建和共享组件。该项目尚未投入生产，因此，此时子模块运行良好。
但是我担心维护和部署，将其转换为 npm 包是个好主意吗？

Answer 1

一个 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 似乎是将软件包链接在一起的好工具)