git 子模块与 npm 包？
git submodule vs npm package?
我正在使用 git 子模块在项目之间构建和共享组件。该项目尚未投入生产，因此，此时子模块运行良好。
但我担心维护和部署，将其转换为 npm 包是个好主意吗？
npm 包将允许跨不同包版本进行分段。另一方面，git 子模块有一点学习曲线，而且工具真的不是那么好。使用 git 个子模块，您可以将所有源代码放在一个文件夹中。
如果可能 all，我建议对所有项目使用普通的 monorepo。您可能需要创建构建时间变量（通过 babel plugin/s），您可能需要从后端获取某种“实时配置”。我使用 git 子模块工作了一年，最近我使用了一个使用 npm 共享代码的项目。
我建议只对所有共享代码使用 一个 git 子模块，而不是几个子模块。我会强烈考虑使用 lerna，并使用你的 one git 子模块来跟踪 lerna 的 packages 目录。如果团队决定他们不喜欢 git 子模块，您可以轻松地将此 repo 设为兄弟 git repo，而不是子模块。然而，最重要的是，我建议使用普通的 monorepo。
这是来自 Netflix 的关于 monorepo 的精彩演讲：https://www.youtube.com/watch?v=VNqmHJtItCs（强烈关注阻止 npm 风格的包）
这是 google 臭名昭著的 monorepo 谈话：https://www.youtube.com/watch?v=W71BTkUbdqE
这是一个很好的阅读网站，可以帮助您思考良好的开发流程：https://trunkbaseddevelopment.com/（它主要提倡 monorepo 方法）
如果您正在为不同的客户开发软件（不同的 people/companies 为类似的项目付钱给您），并且同意它们应该至少 ~80% 相同，您可能真的很喜欢使用构建标志帮助开始拆分功能，但我相信您应该非常主动地保持构建标志周围的代码干净，并重构为可重用 components/packages。给每个客户某种构建-flags.json。构建标志应仅根据功能命名，理论上这些功能都可以单独切换。有些代码可能完全针对每个项目自定义，在这种情况下，您可能要考虑使用动态导入，但通常这是一个我尚未完全克服的痛点，尽管我对此有很多未完善的想法。
如果 monorepo 没有发生，我实际上建议在 git 子模块上使用 npm 包+单独的 repos，假设你可以对包进行良好的语义版本控制。 （而且，yalc 似乎是将包链接在一起的好工具，而不是标准的 npm/yarn link）
我正在使用 git 子模块在项目之间构建和共享组件。该项目尚未投入生产，因此，此时子模块运行良好。
但我担心维护和部署，将其转换为 npm 包是个好主意吗？
npm 包将允许跨不同包版本进行分段。另一方面，git 子模块有一点学习曲线，而且工具真的不是那么好。使用 git 个子模块，您可以将所有源代码放在一个文件夹中。
如果可能 all，我建议对所有项目使用普通的 monorepo。您可能需要创建构建时间变量（通过 babel plugin/s），您可能需要从后端获取某种“实时配置”。我使用 git 子模块工作了一年，最近我使用了一个使用 npm 共享代码的项目。
我建议只对所有共享代码使用 一个 git 子模块，而不是几个子模块。我会强烈考虑使用 lerna，并使用你的 one git 子模块来跟踪 lerna 的 packages 目录。如果团队决定他们不喜欢 git 子模块，您可以轻松地将此 repo 设为兄弟 git repo，而不是子模块。然而，最重要的是，我建议使用普通的 monorepo。
这是来自 Netflix 的关于 monorepo 的精彩演讲：https://www.youtube.com/watch?v=VNqmHJtItCs（强烈关注阻止 npm 风格的包）
这是 google 臭名昭著的 monorepo 谈话：https://www.youtube.com/watch?v=W71BTkUbdqE
这是一个很好的阅读网站，可以帮助您思考良好的开发流程：https://trunkbaseddevelopment.com/（它主要提倡 monorepo 方法）
如果您正在为不同的客户开发软件（不同的 people/companies 为类似的项目付钱给您），并且同意它们应该至少 ~80% 相同，您可能真的很喜欢使用构建标志帮助开始拆分功能，但我相信您应该非常主动地保持构建标志周围的代码干净，并重构为可重用 components/packages。给每个客户某种构建-flags.json。构建标志应仅根据功能命名，理论上这些功能都可以单独切换。有些代码可能完全针对每个项目自定义，在这种情况下，您可能要考虑使用动态导入，但通常这是一个我尚未完全克服的痛点，尽管我对此有很多未完善的想法。
如果 monorepo 没有发生，我实际上建议在 git 子模块上使用 npm 包+单独的 repos，假设你可以对包进行良好的语义版本控制。 （而且，yalc 似乎是将包链接在一起的好工具，而不是标准的 npm/yarn link）