Dependency Resolution

Bit greatly simplifies component dependency management by automating most of it. The dependency resolver aspect detects component dependencies by parsing out import/require statements in the components' files. It then determines their dependency type ('runtime', 'peer', or 'dev'), their module type ('package' or 'component'), and resolves their version.

The version and type of a dependency are determined by the dependency resolver after considering multiple sources, listed here by a descending order of importance:

  1. Component dependency config (defined manually)
  2. Dependencies defined via aspects (programmatically)
  3. Dependencies defined via envs (programmatically)
  4. Workspace dependency policy and Bit's automatic dependency detection (dependency policies only affect components that have the relevant dependencies detected. If a component does not use a dependency, the policy does not affect it).
Development dependencies

Dev dependencies are resolved as such, automatically, when a dependency is only used by the component's development files.

A component's dependency graph is resolved and persisted when it is snapped. It includes:

  • The semver range of packages specified in the dependency policies or dependency configurations
  • The concrete versions of components installed in that workspace, and used by that component. If these components are maintained in the same workspace, and used directly by that component, their latest snaps are registered in the component's dependency graph.
Package installation vs dependency resolution

Package installation is done by your package manager of choice - not by the dependency-resolver.