Règles de révision de Design System

Utilisez ces règles quand vous travaillez dans packages/frontend/ et packages/frontend/@n8n/design-system/. Suivez toujours les recommandations dans packages/frontend/@n8n/design-system/src/styleguide/*.mdx.

1) Priorité source des tokens

Préférez cet ordre quand vous choisissez des valeurs visuelles :

1. Tokens sémantiques depuis packages/frontend/@n8n/design-system/src/css/_tokens.scss
2. Primitives depuis packages/frontend/@n8n/design-system/src/css/_primitives.scss
3. Valeurs codées en dur seulement quand aucun token approprié n'existe

Si aucun token n'existe, demandez une courte justification dans la PR.

2) Valeurs visuelles codées en dur

Signalez les valeurs visuelles codées en dur et suggérez des alternatives tokens. Cela inclut :

• Couleurs (#fff, rgb(), hsl(), oklch())
• Espacement et dimensionnement (px, rem, constantes numériques de layout dans les styles)
• Rayon, largeurs/styles de bordure, et ombres
• Valeurs typographiques (taille de police, poids, hauteur de ligne)
• Valeurs de mouvement (durées et easing comme cubic-bezier(...))

Sévérité : avertissement fort (migration attendue vers tokens/primitives quand possible).

3) Utilisation de tokens hérités

Dans _tokens.scss, la section compatibilité étiquetée « Legacy tokens (kept for compatibility) » est considérée comme une utilisation héritage.

Quand du code nouveau ou modifié utilise ces familles de tokens hérités, signalez cela comme une opportunité de migration et recommandez l'utilisation de tokens sémantiques où disponibles.

Sévérité : avertissement fort (décourager la nouvelle utilisation, autoriser les chemins de compatibilité).

4) Surfaces de style et composants dépréciés

Signalez la nouvelle utilisation de surfaces de style/composants dépréciés ou héritage dans les composants du design-system, par exemple :

• Button.legacy.scss et classes override de bouton héritage
• Variantes/types de bouton héritage (par exemple highlight, highlight-fill)
• Variantes de composant héritage qui existent pour compatibilité (par exemple variante onglets héritage)

Sévérité : avertissement fort (préférer les variantes/composants sémantiques modernes).

5) Changements de substitution de token

Si une PR change une référence de token à une autre (par exemple --text-color -> --text-color--subtle), signalez cela comme un avertissement doux.

Demandez l'intention dans la description/commentaire de la PR :

• Ajustement de design intentionnel, ou
• Potentielle régression visuelle accidentelle

Ne traitez pas la substitution de token comme une défaillance stricte par défaut.