> ## Documentation Index
> Fetch the complete documentation index at: https://docs.commonality.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

Constraints prevent packages from depending on each other in ways that don't make sense but are allowed by your package manager.

They help you maintain a dependency graph that’s easy to reason about no matter how many packages are in your project.

You might want to use constraints to:

* Ensure no package can ever depend on an `application`
* Ensure `data` packages can't depend on `ui` packages
* Ensure `config` packages can only depend on other `config` packages.

## Configuring constraints

Constraints are defined as a [constraint object](/reference/constraint-object) in your [project configuration](/reference/project-configuration) file and can be used to `allow` and `disallow` packages matching a [selector](/selectors).

Here's an example of a configuration that enforces the constraints above:

```json .commonality/config.json theme={null}
{
  "$schema": "https://commonality.co/config.json",
  "constraints": {
    "*": {
      "disallow": ["deployable"]
    },
    "data": {
      "disallow": ["ui"]
    },
    "config": {
      "allow": ["config"]
    }
  }
}
```

## Validating constraints

You can view the status of your constraints by running the [constraint command](/reference/cli#constrain).

```bash theme={null}
commonality constrain
```

## Precedence

A [constraint object](/reference/constraint-object) can contain both `allow` and `disallow` constraints.
When both are present, `disallow` constraints will be evaluated first.