sindresorhus/eslint-plugin-unicorn

Allow some strings in `string-content`

Fermée

#681 ouverte le 11 avr. 2020

Voir sur GitHubGuide contributeur
 (3 commentaires) (3 réactions) (0 personne assignée)JavaScript (468 forks)user submission
enhancementhelp wanted

Métriques du dépôt

Stars
 (5 022 étoiles)
Métriques de merge PR
 (Merge moyen 4h 30m) (26 PRs mergées en 30 j)

Description

Rule: https://github.com/sindresorhus/eslint-plugin-unicorn/blob/master/docs/rules/string-content.md

Issues reported in https://github.com/xojs/xo/pull/439#issuecomment-598751860

I initially suggested this rule in https://github.com/sindresorhus/eslint-plugin-unicorn/issues/327 but I'm not able to use it for my original case because it applies to strings that shouldn't be changed.

I think this rule should instead be applied only in some cases, via whitelist.

An example would be:

  • use variable name, e.g. const description = 'More...'
  • use property name, e.g. {description: 'More...'}
  • use TypeScript type, e.g. FeatureMeta['description']
  • use AST like indent rule’s ignoreNodes (not sure if this is applicable)
  • use JSX attributes and textContent

This would probably replace the current tag-based blacklist.

Guide contributeur

Direction de recherche
Examinez l'implémentation actuelle de la règle `string content` dans `docs/rules/string content.md` et le fichier source dans `rules/string content.js`. Passez en revue la discussion dans la XO PR #439 et l'issue #327 liées. L'objectif est de remplacer l'approche par liste noire par une liste blanche, permettant aux utilisateurs de spécifier les chaînes autorisées en fonction des noms de variables, des noms de propriétés, des types TypeScript ou des types de nœuds AST. Envisagez d'utiliser une option `ignoreNodes` similaire à la règle `indent` d'ESLint. Regardez comment la règle gère actuellement les templates étiquetés et les éléments JSX pour comprendre la logique existante.
Stack technique
javascriptnodejs
Domaine
developer experiencetooling
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Ancienne
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Plutôt claire
Prérequis
ESLint rule developmentJavaScriptAST traversal
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
45