Enforcing architectural boundaries in a front-end codebase is rarely straightforward. According to Sasha Dudkina, developers implementing Feature-Sliced Design (FSD) often face a choice between two prominent validation tools: eslint-plugin-boundaries and Steiger. While both can detect incorrect layer dependencies—such as an entity improperly importing a feature—they tackle the problem through fundamentally different mechanisms.
eslint-plugin-boundaries is a general-purpose plugin that requires you to explicitly define architectural elements and allowed dependencies. Steiger, by contrast, is a dedicated linter that provides built-in FSD checks out of the box, covering import directions, missing public APIs, and slice organization.
Setting Up eslint-plugin-boundaries for Custom Conventions
The primary advantage of eslint-plugin-boundaries is flexibility. Because it has no built-in knowledge of FSD, you can adapt it to non-standard project setups. For instance, if your repository uses capitalized layers such as Features, Entities, and Shared, you can declare those paths explicitly in your configuration.
{
from: {
element: { type: "features" },
},
allow: {
to: {
element: {
type: ["entities", "shared"],
},
},
},
}This approach lets you maintain your existing folder naming conventions without forced refactoring. However, the trade-off is that you must write and maintain the rules yourself. If you forget an architectural constraint, the plugin will not enforce it automatically.
Leveraging Steiger for Strict FSD Compliance
Steiger offers a specialized approach via its official plugin, @feature-sliced/steiger-plugin. According to the comparison, getting started involves a separate CLI and configuration:
npm install -D steiger @feature-sliced/steiger-plugin
npx steiger ./srcSteiger checks more than just import direction. It validates missing public APIs, checks if imports bypass a slice's index.ts file, and verifies segment conventions. Its strictness assumes conventional FSD project structures with lowercase layer names. Adopting it in an existing codebase with divergent patterns may require structural changes.
Making Your Choice
Choosing between the two tools comes down to your project's current state and enforcement needs. eslint-plugin-boundaries suits codebases with established conventions, custom folder names, and a primary focus on dependency direction within the existing ESLint workflow. Steiger fits greenfield projects using conventional FSD where automatic validation of public APIs, folder organization, and slice structures is desired.
As noted in the comparison, these tools are not mutually exclusive. An ESLint setup can handle code quality and custom boundaries while Steiger runs separate FSD checks, provided you avoid duplicate rule overlap. Evaluate what problem you are actually trying to solve before adding a new tool to your pipeline.