When we version or 'tag' a component, we commit changes and prepare it to be exported to a remote scope. This process most often includes compiling and testing, as well.
bit tag <component-id> <new-version>
bit tag ui/button 1.0.0
bit tag <component-id> <new-version> --message "this is the tag message"
Tag all components and bump the patch number of each component version
bit tag --all
bit tag --help or
bit tag -h to get a list of available options for this command.
When collaborating on components it is not advisable to tag a new component release version locally, but instead to have it done by the CI.
- Tag a component using the
--softoption. This will not create a new release version but will update the
.bitmapfile to suggest a new version.
bit tag --soft <component-id>
Commit changes made to the
.bitmapfile (the previous version update suggestion) and push to the remote repository.
Have the CI run the following command to tag all components suggested to be versioned (suggested by the previous 'soft tag')
bit tag --persist
To untag our a component run the following:
bit untag <component-id>
'tagged' or versioned components are components stored in your local scope.
┌──────────────────────────────────────────────────────────────────────┬─────────┬─────────┐ │ component ID │ local │ used │ │ │ version │ version │ ├──────────────────────────────────────────────────────────────────────┼─────────┼─────────┤ │ button │ 1.0.0 │ 1.0.0 │ └──────────────────────────────────────────────────────────────────────┴─────────┴─────────┘
The 'build pipeline' is a series of tasks defined by the environment. In our case, we've set all our components to use the React environment which has, as a default, two tasks in its build pipeline:
- Compile (using the React environment compiler)
- Test (using the React environment tester)
If any of the build pipeline's tasks fail, the tagging is aborted.
As with any other service provided by the environment, the 'build pipeline' can too be extended and customized.
Bit's versioning follows the common semantic structure of [major].[minor].[patch]. As a default, if a version number was not included in the tag command, Bit will bump the patch number.
Bit makes sure to run the tagging process on every component affected by the modified (versioned) component. As mentioned earlier, that process also includes compiling and testing. This process let's us know immediately when another component breaks due to that change.
To see a diagram of the dependencies in your workspace or scope, take a look at the 'Dependencies' tab (in the Workspace UI/ Remote Scope)
The above example uses the
--persistflag to perform a 'hard tag'. In most cases, you would not want to commit changes (and later on, export) components directly from your local environment. It is usually preferable to use 'soft tag' to propose a new version and let your CI set a new version with the committed changes (using 'hard tag')
// soft-tagbit tag <component-id>