This version is not a stable release. To install it run bvm config set RELEASE_TYPE nightly and then bvm upgrade. To learn more see Install experimental release.

The env.jsonc file was recently introduced along with other major upgrades to the envs API. The file, which is located at the root of the env directory, lists the dependency policy for components using that env.

Since the env.jsonc is a static JSON file, and not a function, Bit can read its dependency configuration without running the env. This means Bit does not need to perform the installation process in order for it to get the list of dependencies set by the env (no need to install the dependencies required for the env to function, or to compile it). This, in turn, boosts the installation process as a single installation is needed instead of two, or more.

If you are using a legacy env, you can still use the env.jsonc file to set the dependency policy for your components. To learn more see Using a static dependency policy in a legacy env.

To run the installation process multiple times (as much as needed) use the --recurring-install flag:

$bit install --recurring-install

Copied

External envs (envs that are not maintained by the workspace) are now installed and resolved from the .bit_root directory, inside the node_modules directory of the workspace.

This means envs are no longer created in a capsule which requires its own installation process, and is prone to errors.

Moreover, since envs are installed and resolved from a single location, conflicts between different instances of peer dependencies are better prevented.

To enable this feature, make sure the following is set in your workspace.jsonc file:

/* @filename: workspace.jsonc */

{
  "teambit.workspace/workspace": {
    "resolveEnvsFromRoots": true
  },
  "teambit.dependencies/dependency-resolver": {
    "rootComponents": true
  }
}

Copied

The 'root components' feature handles multiple peer dependencies in a single workspace.

Multiple peer dependencies are expected to be installed when working with independent components, as different components might use different envs, which could have different versions of the same peer dependencies. Moreover, since 'apps' are also components, there are often multiple apps in a single workspace, each with its own peer dependencies.

More on how Bit handles multiple peer dependencies in the a single workspace, in a doc coming soon.

Learn how to extend your Tailwind CSS with plugins, and how to configure it to work with different frameworks.

Read the blog

The blog was updated with new instructions on how to integrate Tailwind CSS with Bit. These instructions are now simpler and easier to follow.

Read the blog

As your projects grow, it gets harder to deliver features fast enough.

Instead of dwelling in your legacy codebase and having endless meetings, you can turn to composability to develop any application part or feature as an independent Bit Component.

You can start small by building a new feature outside your project and adding components to your apps, or by extracting and turning an existing feature into independent components.

In this live coding session, you'll learn how to start creating and using micro frontends in an existing application using Bit Components, without committing to major migration upfront.

Learn how to use the env.jsonc file to set the dependency policy for your components, when using a legacy env.

Read the blog

We highly recommend upgrading your envs to the new envs API.