A development environment ('env') is a collection of tools and configurations a component uses for its development, build, and delivery.
An env is a single component. It can be shared between teammates working on the same project to ensure all components use the same tools and adhere to the same standards, even when they are developed and delivered independently.
Bit offers various envs that you can use as the basis for your own envs. Find the 'Set up an env' page under the framework you're using, to learn more about creating an env for components of that framework.
Run the following to list the components maintained by your workspace, and their envs:
The output lists components and envs maintained by your workspace.
Explore this output by clicking on the components listed!
│ component │ env │
│ my-org.dev/my-react-env │ teambit.envs/env │
│ my-org.tasks-scope/apps/to-do │ my-org.dev/my-react-env │
│ my-org.network/check-ok-status │ teambit.harmony/node │
When you create a component, it is already configured with a default env. This env is set by the same template (generator) that was responsible for creating its source files. For example:
The output confirms that a new component was created, and that its env is 'react-env':
To override the default env set by the component template use the
--env option. For example:
You can also set a component with a different env, after it's been created or even snapped. For example, the following sets the component with 'my-react' env:
The output confirms that the new component is set with the custom env:
To select all components that use a specific env, and replace their env with another env, run the following:
This process is often useful when you want to replace an env with a newer version of it, or when you want to replace an env that you have no permissions to modify, with your own custom env.
Components maintained by the same workspace often use different dev tools and configurations, each component, according to the env it uses. Env services simplify component development by operating these tools via a standardized interface (API, CLI, and UI).
For example, the following runs the compiler service on all components in the workspace, regardless of the specific compiler set by their envs (Typescript, Babel, etc.):
The output lists all components affected by the compilation. Notice how the env (a component itself) and the component that uses it, were both compiled, even though each of them uses a different env (and possibly, a different compiler):
✔ SUCCESS apps/to-do
Explore the different services in the the list below: