野外观察Monorepos的有用工具和想法…
最近，我一直在谈论和讨论扩展代码共享的方法。 一个流行的主题是“ monorepo ”，即多包共享存储库。
将单独的程序包保存在单个存储库中对于代码共享很有用，因为它使团队可以共享其项目的一部分以供其他团队和项目使用，而无需建立和维护许多存储库的开销。
例如，设想一个组织，其中不同的前端团队希望与共享的React组件进行协作和合作。 为了支持这一点，他们构建了一个共享的React库（例如Pinterest的Gestalt或HP的Grommet ）。
为了做到这一点，他们考虑采用“ monorepo ”。 将所有组件都放在一个存储库中，而每个组件都是自己的程序包。 这种“有用的邪恶”也使贡献，运行CI / CD和管理变更变得更加容易。
在这篇文章中，我将回顾并分享有关生态系统中最佳工具和解决方案的知识，以实现这一目标。 根据您的经验，随意发表评论并提出自己的见解和工具！
1.比特成分monorepo
关于Bit的事情是，每个存储库已经是一个monorepo。
您不需要重构任何东西。 您不需要重组项目，设置不同的程序包，定义package.json文件或其他任何内容。
相反，您只需要将Bit添加到存储库并共享组件。 由于Bit具有自动将组件与项目隔离的能力，包括其所有依赖关系以及更多其他功能，因此这成为可能。
在将Bit添加到存储库后的数分钟之内，可以共享数十个组件，以在Bit的中心中可用，可以在此对其进行组织，共享和在线播放，然后与NPM和Yarn一起安装。
当您对存储库中的一个组件进行更改时，Bit将自动跟踪更改并识别将其用作依赖项的其他组件。 然后，如果您运行bit status ，则可以看到所有组件，因为它们的依赖关系已被修改，这些组件已被自动修改。
意思是，无需手动浏览package.json文件来管理对依赖项的更改，因为Bit可以帮助您简化Monorepo的维护工作。
您还可以将Bit添加到库的版本管理（CI / CD）中，以使用所有更改来更新每个版本上的组件。 由于Bit可以运行，构建和测试组件，因此您可以快速了解所有内容的新状态。
PR可以直接制作到monorepo，也可以通过bit import来制作，其他人可以直接从其最终项目中导入和开发组件。
综上所述，如果您有一个组件库要制作一个多包的monorepo，Bit可能是最快，最省力的方法。 它还提供了附加值，如可发现性，在线社区等。
试试看 。
例
位之前的语义UI组件库。
带有位（0重构）的语义UI组件库。
优点
- 0重构到存储库。 从0到从您的现有库发布100个软件包需要几分钟。 尝试一下。
- 可扩展的代码共享，无开销。
- 绝佳的视觉可发现的部件。
- Bit自动管理回购中的所有依赖项，包括对组件依赖项的更改，并根据需要更新所有组件。 没有其他要维护或更新的
package.json文件。 - 可以通过PR到存储库进行更改管理，也可以通过导入任何组件，进行更改并向原始存储库发布更新来从任何其他存储库发布组件更新来进行更改。
- 版本的自动更新（CI / CD中的位）。
缺点
- 扩展系统即将启动。 在此之前，您可能必须针对使用的不同工具稍微修改构建/测试环境。
- 通过Bit的注册表与NPN / Yarn客户端一起打包安装（您的选择）。 不支持NPM的注册表。
- 该中心的所有功能（搜索，操场，npm安装）都要求您在该中心托管代码（例如GitHub和NPM）。 没有供应商锁定（位像Git一样分布，可以在任何服务器上设置）。
2. Lerna Monorepo
Lerna是用于在单个存储库中管理多个软件包的工具。
使用Lerna，您可以重构您的存储库以在其中存储多个软件包，而Lerna允许您链接依赖项（ lerna bootstrap)并根据您的选择对它们进行单独或一起版本化（独立模式意味着每个子软件包都有自己的服务端并在其依赖项更新时进行相应的更新）。
my-lerna-repo/
package.json
packages/
package-1/
package.json
package-2/
package.json
Lerna自动执行monorepo中软件包的任务。 lerna run build将在每个子软件包中运行npm run build并且lerna publish将所有软件包发布到npm并更新git标签等。然后，可以从NPM的注册表中安装软件包。
Lerna在开始时需要做一些工作，并且需要更多工作，但是这是将少量核心程序包保留在单个存储库中并将其独立发布到NPM的可靠方法。
一些开源项目使用Lerna处理核心程序包，包括Babel，Jest和Gatsby。 它在网络上有许多教程和帖子。 这对于在一个存储库中管理单个项目的多个部分特别有用，而每个部分本身都是独立的“微型项目”。
例
优点
- 网络上有许多成熟的教程。
- 单独或在一行中对所有软件包进行版本控制。
- 使用
lerna bootstrap链接项目中的依赖lerna bootstrap。 - 自动执行仓库中所有软件包的任务。
-
Lerna publish发布NPM的所有更新。
缺点
- 大量重构存储库。 大量的初始开销。
- 对于每个包，不同的
package.json和环境会导致维护开销增加。 - 软件包的可发现性取决于NPM /库的文档。
- PR只能在回购中进行，并且很难将新开发人员加入回购中，这反过来会影响软件包的采用。
3. Bit + Lerna + Yarn工作区组合
Lerna和Bit可以在单个存储库中一起玩。
例如，Lerna可用于管理核心软件包，而Bit可用于共享所有较小的组件。 Bit还提供了组件的可发现性，并减少了所需的重构和维护量。
两者还可以与Yarn工作区一起使用。 Bit将自动管理存储库中组件之间的依赖关系，而Lerna将帮助您处理较大的核心程序包，而Workspaces将帮助整合和优化存储库中外部程序包的安装。
优点
- 使用Lerna处理库中的3-4个较大的程序包，而Bit将处理数十个组件。
- 从仓库中共享任何数量的组件没有开销。
- 组件的可发现性和更简单的协作。
- 与Yarn工作区结合使用以优化工作流程和性能。
缺点
- 使用2个工具代替1。
- 您必须手动维护较大的软件包。
- 使用2个程序包注册表（都与NPM客户端一起使用，因此在运行1条命令后不应影响内部消耗）。
4. Git子模块
Git是大多数开发团队的首选SCM。 它允许您将一个存储库作为另一个存储库的子目录 ，为整个项目创建一个工作树 ，并且一个项目可以使用另一个项目中的代码。
但是，对于大多数开发人员来说，Git子模块是一个痛苦的话题。
首先，它们仅在master分支上工作。 其次，子模块会在项目之间创建高度耦合的代码，从而难以在跨仓库任务上进行合并和协作。 子模块存储库也不知道它是嵌套的，并且可能具有从属存储库。
有多种工具可提供围绕Submodule功能的附加自动化功能，例如git-subtree ， gitslave ， braid和giternal 。 这些工具试图改善子模块的某些可用性问题，但不受特定供应商的支持，并且具有不同的缺点。
结论
关于Monorepos的讨论正在社区中蓬勃发展。 尽管大多数人都认同多仓库体系结构的优点，但是一些用例使维护和发布来自多个存储库的多个软件包变得非常困难。 特别是在使用共享库时。
为了简化这一过程，生态系统中出现了新的工具。 从Lerna可以自动进行设置，以围绕在单个存储库中保存和发布较大的软件包，到Bit可以将组件库的使用经验提升到一个新的水平，而这一切都需要0的努力。
最重要的是，共享代码既涉及技术，也涉及人员。 您和您的团队必须专注于编写可重用的代码，以模块化的方式进行思考，并鼓励沟通和效率。 感谢您的阅读，请随时在下面发表评论并提出任何要求。 干杯
From: https://hackernoon.com/4-ways-to-go-monorepo-in-2019-ea5d19fc1f08
扫一扫
2561
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
