bit status command, displays the state of the tracked files in your projects’ workspace and the corresponding code components in the project’s local Scope.
Project Workspace and Bit Local Scope
When you run the
bit status, Bit calculate the difference between the tracked files (and their dependency graph) in the workspace, and compares it to the data saved in the local Scope. Bit will use this comparison to figure out the state of all tracked components and data-objects kept in the Scope.
Before diving into each status, we first need to understand what are Scopes and Workspaces.
Similar to Git, when you run
bit init to initialize an empty Scope, Bit creates a local Scope and sets a working directory (workspace). The workspace is where files are tracked, and components are represented (to be required/imported by your code). The local Scope acts as a database to store all objects and data, relevant to the workspace (for reference, in Git, a repository is the
.git folder that contains all data on the files, commits, branches, etc… Workspace is the project’s directory tree that in it you track files using Git).
The ‘bit status’ command shows the state of the data-objects in the local Scope compared to the projects’ workspace.
Listed here are all possible statuses that you might encounter when running
Nothing to tag or export
This output tells you that there is no difference between the projects’ workspace and the local Scope. There are several cases that may result in this message:
- The local Scope is empty, and no files are tracked in the workspace.
- The Scope has just been initialized and no files are tracked by Bit.
- The tracked files in your workspace are ‘up-to-date’ with the data-objects in the local Scope.
$ bit status nothing to tag or export
A file, or a set of files, are tracked as components. However these files are not found in the local Scope. Bit consider these files as new components, as they have no objects that point to them in the Scope. A new component needs to be tagged, so that Bit will save it in the Scope.
Additionally, Bit tries to to validate if a new component can be isolated, and will print all isolation issues it finds (if any).
Read more about the different isolation issues and how to resolve them.
$ bit status new components (use "bit tag --all [version]" to lock a version with all your changes) > bits/a ... ok
All tagged components, in your workspace, that are ready to be exported and shared to a remote Scope.
Staged component are fully isolated by Bit, and are stored as component-versions. If you have a staged component, you can still perform modifications on it. When you
tag the changes, Bit will create a new version for them (if you do so, it’s best to untag the version before doing any modifications).
$ bit status staged components (use "bit export <remote_scope> to push these components to a remote scope") > string/index. versions: 0.0.1, 0.0.2, 0.0.3 ... ok > string/is-string. versions: 0.0.1 ... ok > string/pad-left. versions: 0.0.1, 0.0.2 ... ok
Modified components are components that already stored in the local Scope, but their corresponding files in the project’s workspace have modifications. Modified components are meant to be tagged and set as a new version for a component.
Note Similar to ‘new components’, Bit will evaluate if it can isolate a modified component, and will notify you about isolation issues it may find. You need to resolve these issues prior to tagging a new version.
$ bit status modified components (use "bit tag --all [version]" to lock a version with all your changes) (use "bit diff" to compare changes) > string/pad-left ... ok
bit import command may fetch newer versions of components that are already found in the local Scope. Running
bit status in this case will result in Bit prompting you that there is a newer version in the local Scope that you can choose to use in your workspace.
bit checkoutcommand to use the newer version of the component.
$ bit status pending updates (use "bit checkout [version] [component_id]" to merge changes) (use "bit diff [component_id] [new_version]" to compare changes) (use "bit log [component_id]" to list all available versions) > string/pad-left current: 0.0.1 latest: 0.0.2
When you delete a component from your workspace (by removing the tracked files), the
bit status command is unable to find the corresponding workspace files of that component in the local Scope. Bit then assumes that you want to delete the component completely, and will suggest you to use the
bit remove command to delete all related objects from the Scope.
$ bit status deleted components these components were deleted from your project. use "bit remove [component_id]" to remove these component from your workspace > bits/b ... ok
Component pending to be tagged automatically
When you modify a tracked component that another tagged component depends on, Bit will want to tag the component in the dependent component with the updated version of its dependency.
For example: component A depends on component B. Both components are tagged. You are making a modification on a file in component B. When you run
bit status Bit lists B as modified, and A as
pending to be tagged automatically. This is because the change in B will affect the functionality of A.
$ bit status components pending to be tagged automatically (when their dependencies are tagged) > string/index ... ok