What is this about?

To ensure our extension's codebase remains consistent with our design system and to promote better theming, accessibility, and visual consistency, we propose the implementation of the color-no-hex rule from the @metamask/eslint-plugin-design-tokens package. This rule aims to prevent the use of static hex color values in our styles, encouraging instead the adoption of design tokens. By enforcing this rule, we aim to maintain a high standard of code quality and design system alignment, facilitating easier updates and ensuring a cohesive user experience.

Scenario

No response

Design

No response

Technical Details

• Objective: Integrate the color-no-hex rule into the extension's ESLint configuration to discourage the use of static hex color values and promote the use of design tokens.
• Implementation Steps:
  1. Ensure the eslint-plugin-design-tokens package is installed and up-to-date in the extension's project.
  2. Update the .eslintrc configuration file to include the color-no-hex rule, setting it to "warn" or "error" based on project standards.
  3. Run ESLint across the extension's codebase to identify instances where static hex color values are currently used.
  4. Replace identified hex color values with the corresponding design tokens from the MetaMask design system.
  5. Conduct thorough testing to ensure that the updates do not introduce visual regressions or functionality issues.

Threat Modeling Framework

No response

Acceptance Criteria

• The color-no-hex rule is successfully integrated into the extension's ESLint setup and actively flags the use of static hex color values.
• All instances of static hex color values in the codebase are replaced with the appropriate design tokens, ensuring alignment with the design system.
• Visual and functional testing confirms that the updates maintain the integrity of the extension's UI and user experience.
• The extension's documentation and developer guidelines are updated to reflect the importance of using design tokens for color definitions.

Stakeholder review needed before the work gets merged

• Engineering (needed in most cases)
• Design
• Product
• QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
• Security
• Legal
• Marketing
• Management (please specify)
• Other (please specify)

References

No response