limichange / blog-v6 Goto Github PK

关于

本文全文想法来自于 https://bradfrost.com/blog/post/design-system-versioning-single-library-or-individual-components/

这个不是翻译。

都放在一起 VS 每个独立开来

This post breaks down the pros and cons of versioning the whole library vs individual components.

比如 ant design 是一个大的整体发布，所有组件在一个仓库里管理，而 atlaskit 则是把每一个组件完全的独立开，独立发布，独立版本号。我们来简单的讨论一下这两个方式的优缺点。

都放在一起

优点

• 简单

  一个仓库里全弄了，简单，bot 啥的也是配置一次就行了。发布也是一次发布全部。

• 保证质量

  整个团队在一个仓库下管理，不会像独立组件那样每人负责一两个，容易互相 review code，issue 也容易及时讨论。

• 全局工具

  一套工具和文档程序就覆盖仓库了，改个配置全部都更新了。也算是简单的优点。

缺点

• 容易影响使用者

  对于大版本更新会非常的吃力，会有很多的 break feature，必须一次性全改了。

每个独立开来

优点

• 用户独立更新

  比如更新按钮，而不要更新日历，日历组件会使用你更新好的按钮组件。

• 必要发布

  只发布自己要发布的组件，其实和上一条一起了，只是两个优点一个对组件库作者，一个对下游的用户。

缺点

• 复杂度上升

  发布流程就会变得很复杂，需要确保每个组件发布成功，如果发布中间炸了，一半没发布，想想就头痛。

• 质量和兼容性难以保证

  没法保证 Button v3.4 同时兼容 Accordion v1.2 和 Modal v5.3，因为仓库里只有最新版本的组件。

• 依赖复杂

  很多组件都依赖了按钮，按钮如果发布了，其他的组件也需要更新，然后需要二次更新，A 依赖了B，B依赖了C。

• 不好统一

  组件升级了肯定是有了变化，如果不及时升级，就会出现方正的日历里有一堆圆角按钮。

所以

we favor versioning the library as a whole rather than individual components

我们倾向于将库作为一个整体而不是单个组件进行版本管理。

面对设计系统的不确定性

design tokens and icons can often operate a bit independently of a component library

可以把 design token 和 icon 独立出来，因为他们都是无依赖的。而且很多时候需要把 design token 生成 css 代码或者 js 代码，独立出来更加灵活。

While these conversations tend to focus on the technical implementation, it’s important to recognize that (like most design system challenges) these are ultimately people problems. Focus on the relationship between library maintainers and library users, and establish sound processes and governance models to build trust in the system and its team.

最终还是为了好用，整个开发流程需要良性循环，不需要那么纯技术。
可以适当的组合。

我想的

组件库也分相当多的种类，还是得看具体的实施情况，包括人员的配置。有些特殊的比如 headless component library 其实可以完全独立开，但是单体开发好像也行，所以无所谓了。而且整体发布的组件库数量远超独立发布，我现在还只见过 atlaskit 和 react-component。