Most of us build our web projects with components. It makes our code more reusable, more maintainable, more testable, and easier to understand and debug.
We often share a few of these components, to be able to use them across projects. A "design system" for the UI, and some sort of a "toolbox" with util functions, for our logic.
Why, then, do we stop there? Why not share and collaborate on everything?
Truth is, it's not that easy to share and collaborate on components. You can group components together in the same repository and publish them as a single package, but then, you're not really "collaborating on components", you're collaborating on a project.
What you really need is a way to develop, share and modify individual components from any project. Why? Because being able to pick and choose the components (and component versions) for your project, and being able to propose changes, increases the likelihood that these components will actually be used (and reused).
That naturally translates to faster development and higher standard of code.
Introducing Bit - an end-to-end solution for component-driven development.
Bit is an extensible development platform that offers everything you need to collaborate on components (that is, instead of only collaborating on projects)
Let's start with Bit's essential features:
Component source-control - essentially, git for individual components.
Isolated component development - that includes isolated rendering, tests and builds.
Component dependency management — auto-generated component dependency graphs, and smart dependency management. That includes two types of dependencies: node packages and other components (more on that, later).
The workflow
We will create a Bit workspace, version it using git, and (on top of that) version each of our components (managed by the workspace) independently, using Bit.
Two layers of version-control, one for our entire project and another for our components. As you'll soon see, the two work in harmony to produce better, more effective, collaboration on code.
Bit will not only version each component independently but will also enable us to develop, test and build, each of them independently.
Our project repository (the Bit workspace) will be pushed to Github.
Our components (source-controlled by Bit and managed by the Bit workspace) will be pushed to a remote Bit scope
To collaborate on components before they are tagged with a new release version, we will suggest a new release version by updating our workspace. Once that workspace is pushed to Github, the CI (Github Actions) will act on these suggestions, tag the suggested components with a new release version and push them to a remote Bit scope (where they can be cloned into other Bit workspaces).
1. Initialize Bit and git
A Bit workspace is where multiple components are developed and composed together, while maintaining each as an independent project.
$ mkdir my-workspace # create a directory for our workspace
$ cd my-workspace
$ git init # initialize git
$ bit init --harmony # initialize Bit
The following files were created:
├── my-workspace
└── .git
├── bit
├── ...
├── .bitmap
└── workspace.jsonc
workspace.jsonc - The workspace configuration file that sets rules and policies for the workspace and all its components.
Notice there is only one configuration file for all our future components. That's possible thanks to Bit's CSS-like configuration system, where group of components are selected and configured together, and where specific selections override the more general ones.
.bitmap - This is where component files are mapped to component IDs, so that Bit would track them and manage them as a discrete unit (essentially, this is where the "isolated development" starts).
.git/bit - Your local scope. Where your workspace component repositories are stored.
2. Create component files, source-control and manage them as independent components
Let's create two React components, a 'button' and an 'app-bar'. Each component will have its own directory.
├── my-workspace
├── .git
├── components
├── button
└── app-bar
├── .bitmap
└── workspace.jsonc
Each will have the following files:
*.ts - the component implementation files
*.compositions.tsx - the component isolated previews
*.spec.ts - the component tests
*.docs.mdx - the component docs
index.ts - the component entry file
To track them we'll run:
$ bit add components/button
$ bit add components/app-bar
Our components are now each managed and source-controlled independently.
Our tracked components are now also visible in Bit's workspace UI. To see them, run Bit's server, and open localhost:3000
$ bit start
3. Run each component's CI and tag it with a new release version
Our components are ready to be built and tagged with a new release version.
We'll version button as 1.0.0, and app-bar as 0.0.1.
$ bit tag button 1.0.0 --message "public release"
$ bit tag app-bar 0.0.0 --message "initial version"
The above tag command will not only version our components but will also build them each in their own isolated environments. That is, it will copy their source files and configurations (set in the workspace.jsonc) to a directory that is isolated from the rest of the workspace. Once that's done, it will test and build them.
The build workflow, the test runner, the compiler, the linter, and other development tools - are all determined by a pre-configured shareable component development environment. Learn more about it here.
The artifacts produced by the build process will all be versioned as well, along with each component's source-files and configurations.
One of the versioned artifacts is the component's package (with an auto-generated package.json file). The package is used by other components when:
- Using a component authored in the same Bit workspace
- Using a component cloned into a Bit workspace
- Using a component installed (as a package) using Bit or any other npm client
...
Collaborating on components
4. Export (push) and import (clone) components
Just like git repositories are pushed to remote hosting (like Github) so do component repositories are pushed to remote Bit hosting, remote "scopes".
To 'export' (push) components to remote scopes, run:
$ bit export
The remote scope to push the components to, is set in the workspace.jsonc configuration file.
A remote scope can be created on bit.dev for free, or by hosting on your own server.
To 'import' (clone) a component into a Bit workspace, run:
$ bit import <component-id>
Shared components can be found on bit.dev (or on your self-hosted Bit scope).
5. Suggest a new component release version with Bit and git
Instead of locally tagging a component with a new release version (and exporting it from your local machine), we can run:
$ bit tag --soft <component-id> <new-version>
This will update the .bitmap file with the suggested version (without actually tagging the component with a new release version).
Once we push the workspace to Github (along with the .bitmap file) others can review the suggested changes, and your CI can “hard tag” the suggested component versions. and export them. Learn more about this process here.
$ git commit -am "change the button font. suggest new release version"
6. Push the Bit workspace to Github and Run a CI to tag the modified component with a new release version
Go to Github and create a new secret variable in your Github repository.
Name it
BIT_TOKENand set the value of it to theuser.tokenvalue.Create a new
tag-and-export.ymlfile in your remote repository./.github/workflowsdirectory.Create your script:
# This workflow hard-tags and exports soft-tagged components
name: Tag and Export Components
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
tag-and-export:
runs-on: ubuntu-latest
if: "!contains(github.event.head_commit.message, '--skip-ci')"
env:
BIT_TOKEN: ${{ secrets.BIT_TOKEN }}
steps:
- uses: actions/checkout@v2
- name: Use Node.js 12
uses: actions/setup-node@v1
with:
node-version: 12.x
- name: Install Bit Version Manager
run: npm i -g @teambit/bvm
- name: Install latest Bit version
run: bvm install
- name: add bvm bin folder to path
run: echo "$HOME/bin" >> $GITHUB_PATH
- name: Set up bit config
run: |
bit config set analytics_reporting false
bit config set anonymous_reporting false
bit config set user.token $BIT_TOKEN
- name: Install packages using bit
run: bit install
- name: Hard-tag pending components
run: bit tag --persist
- name: Export components
run: bit export
- name: Commit changes made to .bitmap
run: |
git config --global user.name '${{ github.actor }}'
git config --global user.email '${{ github.actor }}@users.noreply.github.com'
git add .bitmap
git commit -m "update .bitmap with new component versions (automated). --skip-ci"
git push
The above script installs Bit, hard tags the new release suggestions (found in the .bitmap file), exports the newly tagged versions and commits the changes made to the .bitmap file (the release suggestions have been replaced with new releases).
See demo project on Github:
teambit
/
harmony-with-github-actions
A demo project: Component collaboration using Bit, Bit.dev, git, and Github.
Learn more about Bit:
Website | Docs | Community | Bit Cloud
Bit is a complete solution for building composable software. It simplifies the creation, maintenance and reuse of software using independent and reusable components.
You can use Bit components to build new projects or reuse components to modernize your existing applications. Here are few examples to components people build with Bit:
- Reusable components
- Backend services
- Design systems
- Composable platforms
- Shell applications
- Micro frontends
Bit supports all tooling in the JS ecosystem and comes out of the box with official dev environments for NodeJS, React, Angular, Vue, React Native, NextJS and far more. All are native to TypeScript and ESM and equipped with the best dev tooling.
Bit is a fit to every codebase structure. You can use Bit components in a monorepo, polyrepo, or even without repositories at all.
Getting started
Install Bit
Use the Bit…
Top comments (1)
Thanks for your posting.
But I can't know.
Could you explain in more details.