构建适用于您微前端架构应用的UI库

一个精心设计的UI库是灵活的，这种灵活性应该在使用、扩展或修改库的过程中显现出来。

在软件开发中，这种情况很常见，灵活性通常通过构建松散耦合和互操作的组件来实现，这些组件可以组合成可组合的软件。

例如，参见此自定义 Material UI 库。此库中的组件可以单独调用或使用；它们可以单独进行版本控制，单独文档化，甚至可以在使用它们的任何项目中作为独立组件进行维护。

在本演示中，组件可以从 Bit 的注册表、NPM 注册表，甚至是 esm.sh 这样的 ESM 注册表（在运行时使用）中获取。

比特值：

https://bit.cloud/bit-bazaar/design/~components?aggregation=none

Git:代码库

构建一个由小型独立组件或包组成的UI库可能会变成一场噩梦，因为每个包都需要自己的package.json配置，这些配置可能包括第三方依赖项以及其他来自相同项目的内部依赖项，以及其他来自相同项目的内部依赖项。

这简化了维护过程，因为你只需要维护一个 package.json 文件，同时整个库也只需要一个构建和版本管理。

不过，这种方法无法满足我们的需求。你并没有多个松散耦合的小代码库，而是一个大型且组件紧密耦合的代码库。这使得库更加脆弱和难以维护，更难排查错误，并且更难扩展和响应新需求。

使用Bit，你再也不用手动配置每个组件了。相反，Bit 会自动检测你组件的依赖，并智能解析它们的类型和版本信息。

当生成一个包的时候，检测到的依赖会包含在它的 package.json 文件里。

Bit 会按正确的顺序进行构建和打包每个模块。例如，假设 icon-button@0.0.1 依赖于 button@0.0.2，Bit 会自动检测到依赖关系，并将它添加到 icon-button 的 package.json 中。

如果修改了**_button_**会怎样？ Bit 会对 button 进行构建，将其版本升级到 0.0.3，并自动为 icon-button 运行构建，该构建包含了 button 的新版本 0.0.3 版本。

如何让用户建议修改UI库？

位组件可以作为独立的代码单元进行维护和更新。无需切换到另一个仓库并摸索新的代码库。你可以将你想要修改的组件拉取到你的仓库中，进行修改，然后提交变更请求，等待UI库维护者审核并合并。这种在同一企业内团队之间的协作，也称为InnerSource（内部开源）。

正如之前所说，通过提供小型且简单易懂的代码库而不是一个大型复杂的代码库能够吸引更多贡献。