Enforcing Your Design System with ESLint (Lightning Talk)

Presented at React Boston 2019. This lightning talk explores how ESLint can enforce design system rules to prevent technical debt from becoming technical liability.

Key Takeaways

• Design systems benefit startups more than mature companies
  Early adoption prevents the accumulation of technical debt that becomes increasingly expensive to fix later
• ESLint enforces product standards, not just code standards
  Custom ESLint plugins can forbid hard-coded colors and deprecated components, ensuring design system compliance automatically
• Automation removes the human review burden
  When ESLint tests pass, nobody needs to manually check design system compliance, streamlining the review process
• AST manipulation enables precise rule enforcement
  ESLint analyzes code as an Abstract Syntax Tree, allowing rules to target specific patterns like forbidden components or colors
• Small teams can maintain high standards without extra resources
  Automated enforcement allows startups to maintain design consistency without dedicated design system teams

The Problem: When Speed Leads to “Shippy” Disaster

The urgency to ship new features often takes precedence in fast-paced tech companies, but this velocity can lead to an incoherent and disorganized application.

“Shippy” serves as a conceptual product illustrating this problem. As companies iterate rapidly (changing branding, adding features, trying new buttons), they often forget to remove older, non-performing elements from the codebase. This continuous, undisciplined iteration turns what should be “technical debt” into a “technical liability,” making the product perform poorly and the codebase difficult to manage.

Design Systems Aren’t Just for Mature Companies

Many companies mistakenly believe that design systems are only for mature organizations with large teams and ample bandwidth. However, a design system provides the most help at the beginning. It prevents products from becoming disorganized and ensures they maintain consistency as they evolve.

The challenge for smaller teams is the lack of human resources to enforce these standards. This is where automation becomes crucial.

The Solution: ESLint as a Product Standard Enforcer

While ESLint is commonly used to set coding standards and ensure code correctness, it can also enforce product standards. By implementing custom ESLint plugins, teams can enforce design system rules directly within their development workflow.

How it Works: Under the Hood with AST

ESLint operates by analyzing code as an Abstract Syntax Tree (AST). Tools like AST Explorer allow developers to visualize how their code is represented in this tree. This makes it possible to write rules that target specific code patterns. For instance, a rule could forbid the use of the generic Text component from react-native if the design system has its own Typography component.

Introducing eslint-plugin-design-system

The eslint-plugin-design-system package provides a collection of rules designed to enforce design system guidelines, specifically helping to remove “vestigial components” and “vestigial colors” as the design evolves.

Key Rules Demonstrated

The no-custom-colors rule prevents developers from using hard-coded color values or unapproved color constants. If enabled, ESLint will flag any color not part of the approved design palette, ensuring visual consistency across the application.

The use-design-system-components rule allows teams to forbid the use of specific components or modules. It can forbid generic React Native components like Text, pushing developers to use the design system’s own Typography or Header components that adhere to predefined fonts and colors. It can also deprecate old design system components, warning or erroring when a developer tries to use a component that is no longer approved (like an “old button” that has been replaced).

The Benefits

These rules provide immediate feedback in the developer’s editor, making it clear when they are deviating from the design system. This automated enforcement eliminates the need for manual review of design system compliance.

By automating design system checks, when the ESLint tests pass, nobody needs to manually verify design system usage. This streamlines the review process and reduces friction between designers and engineers.

The approach ensures that the app’s UI remains consistent and coherent, reducing cognitive complexity and decision fatigue for developers. Teams can focus on building features rather than debating which components or colors to use.

Configuration

Configuring these rules is straightforward. Teams can specify forbidden modules or components directly in their ESLint configuration file. The plugin integrates seamlessly with existing ESLint setups, making adoption simple for teams already using ESLint.

Looking Forward: Be Ambitious!

Disciplining codebases early is paramount for the long-term health and maintainability of products. Engineers should think creatively about how tools like ESLint can be used beyond just code correctness to solve “product correctness” challenges.

By embracing such proactive strategies, teams can iterate faster with confidence. Design changes are consistently applied and the application maintains a high standard of quality throughout its lifecycle. The approach transforms ESLint from a code quality tool into a comprehensive product quality enforcer.