官网

Github

Bit makes it easy to share and manage components between projects and apps at any scale. It lets you isolate components from existing projects with 0 refactoring, with fully-automated dependancy definition/resolution and scalable versioning. It lets you reuse individual components across projects, using your favorite package managers like npm and yarn through Bit's component hub. It lets you extend Git's workflow to develop components from any consuming project , suggest updates and easily sync changes across your codebase.

译：

Bit可以轻松地在任何规模的项目和应用程序之间共享和管理组件。它可以让你通过0重构来隔离现有项目中的组件，具有完全自动化的依赖性定义/分辨率和可扩展的版本控制。它可以让你在项目中重复使用各个组件，通过Bit的组件中心使用您最喜欢的包管理器如npm或Yarn。它可以让你扩展Git的工作流程以便从任何普通项目开发组件，建议更新并轻松地同步代码库中的更改。

最早一次提交在 2016年 11月。

文档中的一大堆 lets you ，看完以后看没看懂不知道，反正是让我心血澎湃了一会儿。

那么这个东东到底是做什么的呢？让我做为一个"吃螃蟹的"先给大伙体验一番。

官网介绍

首先我去了bit的官网：https://bit.dev（一个很大气的域名）。

下面有一段英文视频介绍，其中介绍了bit 的一次完整工作流，不算太难懂。感兴趣的同学可以去看一下。

紧接着，查看了他的文档介绍 https://docs.bit.dev/。

总体来说，文档是比较清晰的。

简单的看了下Bit自己的介绍和文档，可以大致了解到Bit可以为团队协作、个人库维护等工作工程中解决以下一些问题：

公共组件、代码片段便捷发布
公共组件、代码片段便捷导入
公共组件、代码片段版本控制
公共组件、代码片段快速索引及选用（实时编译、实时预览）
公共组件、代码片段自动测试执行
公共组件、代码片段文档生成
结合配置CI自动完成NPM发布
标准化开发规范

所以，如果你们团队能够完整使用bit这一套流程。

那么可以肯定的是，你们的团队的开发流程一定是规范的，你们团队的组件质量也是可以保证的。

现在，我们还是跟着官方的文档实际操作一下先吧！

Quick Start

了解Bit的基础知识以及如何在团队之间共享项目组件。

安装Bit

npm install bit-bin -g

当然还有其他安装方法，详情查看安装方法。

在你的项目中初始化Bit

选择你想要使用Bit的项目目录，在项目目录中初始化Bit工作空间。

$ cd project-directory
$ bit init

这里，我尝试拿已有的项目进行一次bit使用，发现在发布过程中，Bit还会检查所有依赖项，并进行依赖发布。

所以为了快速体验，我随便新建了一个项目，写了一个无依赖的 Component。

import React from 'react';
import { Alert } from 'antd';

function DemoMessage(props) {
  const { content = '' } = props;

  return (
      <Alert {...props}>
        <span dangerouslySetInnerHTML={{ __html: content  }} />
      </Alert>
  );
}

export default DemoMessage

使用Bit跟踪组件

示例：跟踪存储库src/components目录中的所有组件。

bit add src/components/*

Bit遍历所查找的跟踪文件import和require语句，以定义和生成每个组件的依赖关系图，从而无需package.json手动为每个组件定义和管理文件。

Example

拿我的组件感受一下，首先看看我的目录结构：

所有2个组件都在src/components/*。所以可以使用bit add来跟踪它们，这就是你所定义的工作区(下文会多次提到)内的所有组件：

$ bit add src/components/*
tracking 2 new components

可选：你可以直接在组件目录写spec或test指定后缀的测试文件，Bit在发布过程中可以自动执行并返回结果。参考单元测试配置

定义编译器

Bit允许您为项目中的组件定义编译器。要定义编译器，请运行以下bit import命令：

$ bit import bit.envs/compilers/babel --compiler

the following component environments were installed
- bit.envs/compilers/babel@0.0.7

您可以从此预制集合中选择编译器，或实现您自己的编译器配置。

Useful compilers:

定义测试框架

如果你需要同时上传组件的测试文件，你可以定义用于运行它们的测试框架。要定义测试框架，请运行以下bit import命令：

$ bit import bit.envs/testers/mocha --tester

the following component environments were installed
- bit.envs/testers/mocha@0.0.7

您可以从此预制集合中选择测试框架，或实现您自己的测试配置。

设置组件版本

在打包发布之前，你要为组件设置版本，请使用该bit tag命令。

Bit锁定每个组件的依赖关系图的状态，使其版本不可变。

标记组件时，Bit首先运行组件的构建和测试任务。

您可以使用—all命令来标记工作空间中的所有组件。

$ bit tag --all 1.0.0

3 components tagged | 3 added, 0 changed, 0 auto-tagged
added components: components/button@1.0.0, components/login@1.0.0, components/logo@1.0.0

导出组件

现在我们的组件已经被跟踪并且定好了版本号，现在需要将它们导出（发布）到远端集合。

远端集合可以为你托管和组织组件，这可以在任何其他项目和应用程序中快速发现和使用每个组件。(这里可以理解为git的remote，只不过bit的remote还可以为你的组件提供实时预览，文档，展示索引等功能)

首先，转到bit.dev并创建一个免费帐户（如果您还没有帐户）。

然后，创建一个私人或公共集合。

返回CLI并验证Bit登录到你的bit.dev帐户。

使用bit login命令登录，Bit会自动打开浏览器进行身份验证😎。

$ bit login

Your browser has been opened to visit: http://bit.dev/bit-login?redirect_uri=http://localhost:8085...

现在，您已准备好发布组件。

使用 bit export 命令将工作区中的组件发布到 bit.dev。

$ bit export user-name.collection-name

exported 2 components to collection user-name.collection-name

转到你的bit.dev 控制台(工作台) 查看......

这时，你就可以看到所有组件都已导出。Bit也将在集合页面中显示组件的预览效果。

在其他项目中使用组件

现在我们的组件可以说已经上云了，那么在其他项目中可以通过各种方法使用Bit组件。

使用包管理器（如NPM和**Yarn）**Bit提供了兼容NPM的方式，只需要设置npm的@bit scope 下的registry就可以了！

npm config set '@bit:registry' https://node.bit.dev

然后使用组件页面中的install命令，使用您喜欢的包管理器安装组件。示例:

npm i @bit/mui-org.material-ui.button

在多人协作项目中开发Bit组件

根据上面的操作，你可以看出，使用Bit进行组件维护，最好需要将你的组件与你的项目完全解耦。当你的团队是这样做的时候，那么你可以再任意的终端方，开发Bit组件。

要从使用repository开发组件使用该bit import命令。示例：

bit import mui-org.material-ui/button

这个新的工作流程增加了组件的采用和使用，因为开发人员可以直接从不同的项目[导入]和开发Bit组件。

提示：使用此eject 命令从本地工作空间中删除组件并由NPM安装它们。

更新组件更改

使用bit import方式可以直接在你的项目中更新对导入组件中做更改，并在项目之间进行同步。

完成更改后，你可以直接使用bit tag命令为他们制定新版本并发布（如果你有权限的话）。或者，你可以将更改的组件导出为新组件。

当使用集合中的组件有新版本更新时，你可以非常快捷的同步更新该组件所在的每个项目。

提示：使用该bit checkout 命令更新工作空间中的组件版本，包括其依赖关系树。

合并更改

Bit扩展Git以允许合并组件的更改，包括处理合并冲突。此工作流程可帮助您的团队在开发不同项目的组件时同步更改。

Happy coding!

总体感受

在跑完了Bit的基本流程后，对它的优势和引入预演的成本做了一些列的分析。

首先，Bit的社区是比较活跃的，在2019.6.20 20:32 为止，Bit的最新一次提交时间是6.19号，也就是昨天。

但是比较奇怪的是，按理来说这个项目在16年到现在已经不少时间了，在圈中竟然完全搜不到关于他的任何讯息及中文文档。我第一次看到它的时候是在vue的官网上，Bit作为赞助商之一出现vue官网第一位。

而且Bit官方竟然完全不考虑做多语言的适配，连一份README-zh都没有！虽然是个好东西，但不重视我天朝，信不信我天朝智慧人民分分钟撸起袖子搞一套出来。

另外，从名字上看Bit，与git相似。所以其接口设计大多与git相似，所以上手起来非常快。但是！它不支持，私有部署！没错！它学的是GitHub，不是GitLab！也就是说，你可以部署一套Bit服务端，使用bit remote 将你的component发布到自己的服务器仓库，但，你却不能拥有它官网的实时预览与组件列表。至少目前为止还没有！

也就是说，如果你不使用官网提供的remote，那么你将失去团队协作中查看组件预览，组件demo编辑等等功能，对前端组件来说，没有这一点，单纯做远端存贮，这简直如同鸡肋呀！

所以，从一定程度来讲，Bit是一个商业项目，但谁能清楚后面的发展呢，说不定哪天就出现一个BitLab什么的。😂

但必须承认，Bit的这种前端代码片段的管理方式是值得学习的。

规范前端组件，有效解耦组件

随着前端圈子日新月异的变化，几乎每个前端都能在嘴边挂着组件化模块化。

但是真正做到组件化、模块化开发的项目缺寥寥无几，几乎在每个React/Vue的项目中都能看到components的目录。但是查看组件源码，却能看到很多相对路径的import，这意味着什么？

意味着，很多在components目录下的组件以及和原本项目已经有着千丝万缕的联系。

当有一天我们真的想把它从一个项目中拆出来，给另外一个项目用时，就会发现这真的是根本拔不完、抽不出，有些组件中甚至引入了项目中所用的Store。

有时候这并不是项目Owner和前端Leader的责任，很多前端开发者在做项目的时候，明明心里清楚，Components里面的组件应该需要独立抽离。

但是遇到有一些场景，就是这样使用项目中的模块就是最快的方式，一想这样也可以用，而且这个组件应该不会给其他项目用吧，然后心一横，就这样吧…..

而且对于组件文档，组件单元测试，写组件DEMO这就跟不用说了，常年都是被大家忽视，因为没有要求，又麻烦，又不是不能用！

如果前端的工作方式都能切换到bit的这种工作方式进行相互合作，那么从发布方式，规范，标准上就已经被大家所接受。

因为不这么做发布不了啊，别人用不了啊，别人看不到啊，别人看着嫌丑啊！

那么自然而然的，大家对组件质量和组件周边建设的重视性就会逐步提高。

组件编译环境

在大部分前端项目中，一个团队在一开始的发展中，一般就是维护开发一个项目，所以Owner觉得抽不抽离的不是那么重要！

不是咱不想抽那些包，不是咱不想玩那些花哨的，不是咱技术上没考虑到或者达不到。

纯粹就是因为，觉得没必要！能抽离，但是没必要😂！

你瞅瞅，这都是啥，这都是啥。

能力越大（技能越骚，TypeScript Sass React Vue），要整个这环境就越麻烦。

现在我们看看Bit的工作方式，如果要对一个组件的抽离，直接对该组件的目录bit export就可以了，连同npm包都可以发布。

管你是React+TyepScript还是Vue+TypeScript，bit export 就是了，Bit都能给你展示咯，而且这一切不用你配置任何webpack和babel的东西。

这对于抽离一个组件，让他可以快速展示给团队其他成员，并且有一份完整的文档说明和demo展示，就是变成了保证它的解耦 + 一行 bit命令 的事情。

并且相对于NPM包的各种Link式开发，各种项目切来切去，Bit的这种包维护的方式更加直接，更加友好，我几乎不用考虑项目中所使用到的组件都是被版本控制、被包引入的。

那我觉得，有必要了。。😂

版本控制

越是经验丰富的工程师，越是明白版本控制和迭代开发的重要性。

在现在的互联网公司中，前端项目版本控制大多靠项目维度打包不同 JS 包后，发布到CDN，然后控制引入包地址的方式运行。

对于组件维度的版本控制却很少，这样随着组件复用程度增加，对于组件的稳定性就要求越高。

试想一下，如果你有多个项目使用了一套自己公司维护的组件库进行开发，而且这套组件已经被使用到多个项目中。

有一个最早的项目使用的是组件库1.0进行开发，后来该项目稳定后就很少有人维护开发了。

但是组件库一直有人在维护，并且版本已经升级到2.0，增加了非常多的组件，对以前的组件也有过接口上的修改。

当有一天有一个新需求进来，要对这个旧项目做更改，其中要使用组件库2.0的某个组件，该组件在1.0中还不存在，这时候如果对这个项目的组件库升级到2.0，那么对于这个项目中的其他页面都会变成不稳定状态，因为没有人进行全量回归。

如果只使用这一个组件，难道要把这个组件从组件库2.0中拷一份出来？这也太恶心了🤢。

这个问题，究其根本还是因为在维护组件库的时候，我们是按照一整个组件库的维度去进行版本迭代的，并没有按照组件的颗粒度进行版本维护。

但组件的颗粒度维护迭代又是不现实的~很多组件会有相互依赖，工具类依赖，而且在使用起来，开发起来都非常不方便。

使用Bit，能让组件颗粒度的维护变得非常简单、成本降低，不用建仓，不用建npm，不用关心谁与谁组合，在项目里用到的Bit组件都会被Track。

开发者有修改都会被视为更新，然后提交到Bit仓库，开发者可以对任意一个组件进行锁版本，更新版本，回滚，甚至fork一份做个性修改。

而这一切都只是在你的业务项目中就可以完成的，这是不是非常棒呢~

技术沉淀

试想一下，如果你作为一个项目前端Owner或者一个创业公司的CEO，几个项目下来以后，投资人突然问你，你们团队在技术方面有什么沉淀？

几万行代码？

几篇技术文档？

提高了多少性能？

一年前你们开发这个页面需要1周的时间，好了，现在你们做了这么长时间，怎么做个新项目还要一周时间，还有这种小数点3.333333333333333333333334的低级错误？

一个有远见的Owner和Leader会考虑更长远的规划。今天我可以支撑3个项目组，明年我可以支撑8个项目组，靠的不是加班和招更多的人，靠的是自己团队的技术建设和沉淀。

结语

OK，关于Bit的体验和见解，就是这么多了。

总的来说，Bit还是为前端组件、代码片段管理提供了一套不错的解决方案，虽然国内也有类似的东东，但感觉有点不够份量。

PS.人家老外的项目文档写的是真详细啊，天朝智慧人民，社区做贡献的时候要记得多考虑周边建设啊，别人能看懂才是最重要的！

原贴地址：https://yeee.wang/posts/4a20.html

作者博客：https://yeee.wang/

转载请注明作者及原贴地址！