Importing components

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:

$bit
Copiedcopy
See command synopsis

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:

installing dependencies using pnpm
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 another component, apps/to-do. Any changes made to info/icon-text will affect its dependent component, apps/to-do.

TASKS-WORKSPACE
design
node_modules
tasks-scope
.bitmap
workspace.jsonc

Run bit start to explore the imported component in your workspace UI.

Import a component's dependents

An imported component might have dependent components in various remote scopes. Importing these dependents enables you to examine, locally, how changes made to their dependency will affect them. When the component (the dependency) is snapped, bit will auto-snap its dependents.

$bit
Copiedcopy
note

To safeguard against unintentional mass imports, the --dependents flag will only bring in those dependents that are in the workspace's dependency graph, i.e. up to other components in the workspace.

Convert a workspace component to an external dependency

Run the following to stop maintaining a component in your workspace, and use is as an external dependency, instead:

$bit
Copiedcopy
See command synopsis

The output notifies the component package was installed (and added to the workspace dependency policy), and the component's source files were removed:

installing dependencies using pnpm
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 Components

When you fork a component from a remote scope, you create a copy of it in your workspace. This copy is defined as 'new', and has no previous versions. The scope of that copied component is set by default to your workspace's default scope (defined in the defaultScope property).

Run the following to fork a component:

$bit
Copiedcopy

For example, the following command forks teambit.design/basic/button to your workspace:

$bit
Copiedcopy

You can also change the component name by providing a new name:

$bit
Copiedcopy
info

During the fork process, bit will internally refactor the component's file and class names to match the new component name. Add the --preserve flag to skip this internal refactor.

Run the following to fork a component and change its scope to a scope different than your workspace default scope:

$bit
Copiedcopy

Refactoring

If the source component is in your workspace, use the --refactor option to update the import statements in all dependent components (in the same workspace). For example:

$bit
Copiedcopy

All occurrences of import { Button } from '@teambit/design.basic.button' are now replaced by import { Button } from '@my-org/my-scope.basic.button'.