Use Dependencies

For a component to be composable and independent, it must maintain its own dependency graph. This graph can include packages, as well as other components.

To add a dependency to a component, include a standard import/require statement in any of its files. Bit will automatically detect these statements and include them in the component's dependency graph.

For example, the following adds the teambit.design/inputs/input-text component as a dependency of my-org.tasks-scope/apps/to-do component:

import { InputText } from '@teambit/design.inputs.input-text';
CopiedCopy
See full code snippet

Notice how this dependency is consumed as a standard package, even though it is a component. This would remain the same, even if that dependency were maintained in the same workspace. Bit makes this possible by generating a package for each component, during the components' development and build phases.

Consuming components via their (absolute) package name, makes them usable in any context, whether it is a different workspace or even a non-Bit project.

Run the following to install the the above dependency:

$bit
Copiedcopy
See command synopsis
Installing components in non-Bit projects

You can install components using standard package managers like npm and Yarn, in Bit and non-Bit projects. To learn more, see Installing components.

Run the following to review the component's data:

$bit
Copiedcopy

The output lists the installed dependency as a direct dependency of my-org.tasks-scope/apps/to-do:

┌───────────────────┬───────────────────────────────────────────────────────────┐
id │ my-org.tasks-scope/apps/to-do
├───────────────────┼───────────────────────────────────────────────────────────┤
dependencies │ @teambit/design.inputs.input-text@0.0.2- (component)
│ core-js@^3.0.0-------------------------- (package)
├───────────────────┼───────────────────────────────────────────────────────────┤
dev dependencies │ @types/testing-library__jest-dom@5.9.5- (package)
│ @babel/runtime@7.12.18----------------- (package)
│ @types/jest@^26.0.0-------------------- (package)
│ @types/react-dom@^17.0.5--------------- (package)
│ @types/react@^17.0.8------------------- (package)
│ @types/node@12.20.4-------------------- (package)
├───────────────────┼───────────────────────────────────────────────────────────┤
peer dependencies │ @testing-library/react@^12.1.5- (package)
│ react-dom@^16.8.0 || ^17.0.0--- (package)
│ react@^16.8.0 || ^17.0.0------- (package)
└───────────────────┴───────────────────────────────────────────────────────────┘

Bit maintains a dependency graph of all components in the workspace. This graph is used, among other things, to propagate changes from components to their dependents.

To review the full dependency graph of a component, including its indirect dependencies, head over to the component's 'Dependencies' tab in the UI. Notice how this component has 2 additional indirect dependencies.


Dependency configuration

By default, dependencies are resolved to the version installed in the workspace.

In the previous example, the latest version of @teambit/design.inputs.input-text was installed. This version was then used to resolve the component's dependency (i.e, this is the version that was included in the component's dependency graph).

To learn how to control the version and type of a dependency, see the different dependency configuration options in the section below.

Workspace dependency policy

The workspace dependency policy is the default policy for all components in a workspace. It is applied on all components that use the relevant dependency, and is overridden by more specific policies.

The workspace policy is mostly automated. Dependency versions are resolved to the ones installed in the node_modules directory.

To install new dependencies see Dependency installation
To change the semver range of an existing dependency, see Dependency policies

See the Dependency resolution page, to learn how Bit determines the version of a dependency, after considering all the available factors.