Dev environment configuration (env.jsonc)

The env.jsonc file controls the configuration for your component development environments and their peer dependencies.

Peer dependencies are dependencies that are expected to be included once in the development environment and the consuming applications.

// @filename: env.jsonc
{
  "policy": {
    "peer": [
      {
        "name": "react",
        /* the version to be installed and used by the env */
        "version": "^18.0.0",
        /* the range of versions this env's components are compatible with */
        "supportedRange": "^17.0.0 || ^18.0.0"
      },
      {
        "name": "react-dom",
        "version": "^18.0.0",
        "supportedRange": "^17.0.0 || ^18.0.0"
      },
      {
        "name": "@types/react",
        "version": "^18.0.0",
        "supportedRange": "^18.0.0"
      }
    ]
  }
}
Copied

Define your peers using the following properties:

• name. Package name of the peer dependency.
• version. The version of the dependency to be installed in the development environment.
• supportedRange: A semver range specifying compatible versions for your components. This helps prevent version conflicts across your projects.

If your components use the react package, Bit will automatically define it as a peer dependency. You can verify this by running bit show <component-id> to inspect the component's dependencies and ensure your env.jsonc configuration aligns with the desired React version for your project.

You can use env.jsonc to control component dependencies in a graunlar level, and set the env to force specific runtime or dev dependencies to its components.

// @filename: env.jsonc
{
  "policy": {
    "runtime": [
      {
        "name": "classnames",
        "version": "^2.0.0",
        "force": true
      }
    ],
    "dev": [
      {
        "name": "@my-org.design/themes/my-theme",
        "version": "-",
        "force": true
      }
    ]
  }
}
Copied

Use the following proeprties to control dev and runtime dependencies of your dev environment:

• name. Package name of the peer dependency.
• version. The version of the dependency to be installed in the development environment.
• force (optional): Determines whether the dependency is forced to all components.

The example above, sets the classnames dependency to all env components and ensures they do not use the @my-org.design/themes/my-theme component.

Component files can be defined as dev files (as opposed to "runtime" or "production"), and can be configured to be loaded by a specific dev service.

For example:

{
  "patterns": {
    /**
     * a glob pattern for files to be loaded and previewed
     * */
    "compositions": ["**/*.composition.*", "**/*.preview.*"],
    /**
     * a glob pattern for files to be loaded and displayed as docs
     * */
    "docs": ["**/*.docs.*"],
    /**
     * a glob pattern for files to be loaded and executed as tests
     * (by whichever test runner is configured for the env)
     * */
    "tests": ["**/*.spec.*", "**/*.test.*"],
    /**
     * a glob pattern for files to be loaded by no specific dev service
     * but to be considered as dev files (replace "my-dev-files" with whatever name you want)
     * */
    "my-dev-files": ["**/*.dev.*"]
  }
}
Copied

Note that every file handled by a dev service is considered as a dev file.

See the section below to learn about alternative dependency configurations: