fix `color-no-hex` Rule Incorrectly Identifying Non-Color Strings as Hex Values

[georgewrmarshall]

Description

We have identified an issue with the eslint-plugin-design-tokens package, specifically with the color-no-hex rule. This rule is intended to prevent the use of static hex color values in favor of design tokens. However, it is currently flagging strings that resemble hex values but are not intended as colors (e.g., name: 'Captainz #8680',). This false positive can lead to unnecessary confusion and hinder the development process. The task is to refine the rule's logic to accurately distinguish between actual hex color values and similar-looking strings used in different contexts.

Technical Details

• Issue: The color-no-hex rule within the eslint-plugin-design-tokens package incorrectly flags strings that contain '#' followed by alphanumeric characters, mistaking them for hex color values.
• Objective: Update the rule's logic to ensure it only flags genuine hex color values used within CSS-in-JS or similar styling contexts, excluding strings used for other purposes (e.g., names, identifiers).
• Implementation Steps:
  1. Review the current regex or logic used by the color-no-hex rule to identify hex values.
  2. Refine the pattern or implement additional checks to exclude strings that are not used as color definitions.
  3. Test the updated rule against various cases to ensure it accurately identifies hex color values while ignoring unrelated strings.
• Dependencies: This task requires access to the eslint-plugin-design-tokens package's source code and an understanding of its rule validation mechanisms.

Acceptance Criteria

• The color-no-hex rule no longer flags strings that resemble hex values but are not used as colors.
• Genuine hex color values continue to be accurately identified and flagged by the rule, promoting the use of design tokens.
• Developers can use strings containing '#' followed by alphanumeric characters without triggering false positives from the color-no-hex rule.
• Documentation or comments within the eslint-plugin-design-tokens package are updated to reflect the refined logic of the color-no-hex rule.

Additional Notes

This issue highlights the importance of precise rule logic in linting tools to avoid false positives that can disrupt the development workflow. Addressing this issue will enhance the developer experience and ensure that the color-no-hex rule effectively contributes to maintaining code quality and consistency with our design system.

[georgewrmarshall]

Unfortunately, we need to continue recognizing hex values in strings and template literals, and the provided example #8680 is indeed a valid hex value. Therefore, it will be challenging to address this issue .I've conducted a check for false positives across mobile, extension, and portfolio components, and found very few instances. I am closing this for now.

Mobile

• No false positives were found outside of ignored test and storybook files.

Extension

• No false positives were found outside of ignored test and storybook files.

Portfolio

• There was one instance of a false positive, which can be reviewed here.