我正在使用 git submodule 在项目之间构建和共享组件。该项目尚未投入生产，因此，此时子模块运行良好。
但我担心维护和部署，将其转换为 npm 包是个好主意吗？
npm 包将允许跨不同的包版本进行碎片化。另一方面，git 子模块有一点学习曲线，而且工具真的不是那么好。使用 git 子模块，您可以将所有源代码放在一个文件夹中。
如果这是在所有可能的话，我建议你使用纯monorepo所有项目。您可能需要创建构建时间变量（通过 babel 插件），您可能需要从后端提供某种“实时配置”。我使用 git submodules 工作了一年，最近我使用了一个使用 npm 共享代码的项目。
对于所有共享代码，我建议只使用一个git 子模块，而不是多个子模块。我会强烈考虑使用 lerna，并使用您的一个git 子模块来跟踪 lerna 的packages目录。如果团队决定他们不喜欢 git 子模块，您可以轻松地将此存储库设为兄弟 git 存储库，而不是子模块。但是，最重要的是，我建议使用普通的 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 包+单独的 repos，假设您可以对包进行良好的语义版本控制。（而且，yalc似乎是将包链接在一起的好工具，而不是标准的npm/yarn link）