For a component to be maintained and updated, it needs be imported from its remote scope into a workspace.
To import a component to a workspace, copy its component ID from its remote scope, and run the following:
To import and checkout a different snap, include its version (semver/hash) in the component ID. For example:
teambit.design/info/icon-text@0.0.7
.
The output notifies the component was imported successfully. Its source files were checked-out to the working directory and a package (workspace component link) was generated for it in the node_modules
directory, for other components to consume:
✔ running post install subscribers
✔ linking components
successfully imported one component.
- added teambit.design/info/icon-text 8 new version(s) available, latest 0.0.8, currently used version 0.0.8
An imported component is maintained exactly like a component that was created in that workspace. It can be updated, snapped, and exported.
The following workspace shows the imported component (info/icon-text
) being used by apps/to-do
, which was previously created in that workspace.
Any changes made to info/icon-text
will affect its dependent component, apps/to-do
.
Run bit start
to explore the imported component in your workspace UI.
Use the dependents
option to import a component and its direct and indirect dependents, all the way to the highest dependent components that are already maintained in that workspace.
Importing a component's dependents enables you to examine, locally, how modifying it affects its dependents. When the imported component is snapped, bit auto-snaps its dependents (their new snaps are updated to the latest snapped version of that dependency).
For example, assume the following dependency graph:
In this hypothetical scenario, your workspace already maintains the component store-app
. It does not maintain blog-app
.
The following command imports forms/contact-form
, and its dependent, pages/contact-us
. It does not import pages/contact-me
because it is not a dependency of a component that is already maintained in that workspace.
Run the following to stop maintaining a component in your workspace, and use is as an external dependency, instead:
The output notifies the component package was installed (and added to the workspace dependency policy), and the component's source files were removed:
✔ running post install subscribers
✔ linking components
✔ Eject: removing the components files from the filesystem
successfully ejected the following components teambit.design/info/icon-text@0.0.8
To perform the reverse action, to maintain an external dependency (an installed component) in your workspace, import that component to your workspace. The installed package will be replaced by the component's workspace component link.
Forking a component copies its source files and configuration to your workspace. This copy does not include the component's previous snaps as it is a 'new' component.
This can be useful when you want to introduce changes to a component but do not have write
permissions in its remote scope. It's also useful when you need a component that is similar to an existing one, but different enough for it to be a different component.