Dependency Policies

Component dependencies are detected and resolved automatically by Bit. However, the SemVer range and the type of the dependencies to be installed, can be controlled using dependency policies.

Set the workspace dependency policy by configuring the 'dependency-resolver', in your workspace.jsonc file:

{
  "teambit.dependencies/dependency-resolver": {
    "policy": {
      "dependencies": {
        "classnames": "^2.3.2",
        "lodash": "~2.3.3"
      }
    }
  }
}
Copied

The example above shows lodash and classnames listed with a semver range. Every installation of dependencies using the bit install command, installs the latest version in the specified range.

To learn how to configure the dependencies of a specific group of components, see Dependency configurations.

To add a dependency, simply use it in your component. Bit will detect its import/require statement, and infer it as a dependency:

import classnames from 'classnames';
Copied

Run the following to verify the dependency was added to your component:

$bit show apps/to-do

Copied

The output below shows classnames was added successfully as a dependency. Note that lodash is not listed as a dependency since it is not used by this component (even though it is listed in the dependency policies):

To learn how to override auto-detection or dependency policies, see Dependency configurations.

Run the following to list all available updates:

$bit update

Copied

The output lists all outdated (direct) external dependencies, as well as the workspace components using them (in this case, apps/to-do). Select the components to update using the space key and execute the command using the return key.

The new component version is now listed in the workspace dependency policy. This policy updates the apps/to-do dependency graph with a newer version of info/icon-text.

"teambit.dependencies/dependency-resolver": {
    "policy": {
      "dependencies": {
        "@teambit/design.info.icon-text": "0.0.10",
      }
  }
}
Copied

Install and update existing dependencies

When installing dependencies, use the --update-existing (-u) option to update existing dependencies to the latest (or to the versions and types specified in the command).

$bit install --update-existing

Copied

See command synopsis

Dev dependencies are dependencies that are used only during development. A dependency is defined as a 'dev dependency' if it's configured as such in the component's dependency configuration, or if the dependency is only used by the component's dev files (e.g, test files, documentation files, composition files, etc.).

In dependency policies, dev dependencies are listed as regular dependencies, but resolved as dev dependencies for components that use them only for development.

For example, the following lists @testing-library/react as a regular dependency:

{
  "teambit.dependencies/dependency-resolver": {
    "policy": {
      "dependencies": {
        "@testing-library/react": "~12.0.0"
      }
    }
  }
}
Copied

A component that depends on @testing-library/react will most probably use it only in its test file (*.test.* or *.spec.*).

For example, run the following to list the dev files and dev dependencies of apps/to-do:

$bit show my-org.tasks-scope/apps/to-do --remote

Copied

Since apps/to-do only uses this dependency in its test file (listed as a dev file), it is resolved as a dev dependency:

Peer dependencies are dependencies that are expected to be included in a component's host application. Since peer dependencies play a special "public role" in an app, such as the medium of communication between modules or the app's global state, they are required to exist in just a single instance, a single version.

To set a dependency as a peer dependency, use the peerDependencies property:

{
  "teambit.dependencies/dependency-resolver": {
    "policy": {
      "peerDependencies": {
        "@testing-library/react": "~12.0.0"
      }
    }
  }
}
Copied

Although peer dependencies can be configured as dependency policies, they are better configured by the components' env (for standardization). To better understand this, run the following:

$bit show my-org.tasks-scope/apps/to-do --remote

Copied

The output lists react-dom and react as peer dependencies. These peer dependencies are configured via its env (listed here, as well):

To learn more about configuring peer dependencies via envs, see Configuring dependencies from an env.

Note that while components are configured with lenient peer dependency versions, to make them compatible with a wide range of hosts, the host itself (an env or an app use a concrete version.

As mentioned earlier, it is also possible to define peer dependencies through the workspace dependency policy:

Dependencies configured using a package.json, at the root of your workspace directory, are also considered as policy by Bit. However, it is recommended to use workspace.jsonc for more advanced dependency configuration. Also, package.json and workspace.jsonc can be combined on the same workspace. Bit uses both and merges them into a single policy.