Say which projects may depend on which

A UI kit that imports a checkout flow or an app that relies on a helper it should not see is simple to add, yet difficult to remove. Assign tags to the layers and establish the rules once, then lock them. These tags and rules are stored in a project's own configuration file. The workspace defines what each tag can depend on, using selectors such as tag: glob or project-name glob.

The workspace rules specify dependencies, allowing projects to depend on tags like tag:type:app or tag:type:ui, while denying dependencies like tag:type:app or tag:type:feature. If a project has no selected rules, it remains free. The vx lock tool checks the workspace dependencies and workspace rules, refusing any graph that violates the rules, listing every broken dependency and writing nothing.

To resolve the issue, either drop the dependency or adjust the project tags or rules. Once the lock is set, it remains unchanged, so a pull request that introduces a forbidden dependency will fail the test. Runs do not verify these rules; instead, they use the locked configurations from the lock file, which have already passed the checks.

In NX, the @nx/enforce-module-boundaries lint rule reads the depConstraints from the root ESLint config and fills in the workspace rules when none are set. This process creates the workspace rules, which then replace the original rules. However, Nx's lint rule checks source imports, while vx checks the dependencies declared by the projects.

The vx-migrate README also notes other constraints that vx does not check, such as allSourceTags, /regex/ tags, and constraints that only ban external imports. The schema for these configurations can be found in the configuration reference.