Skip to main content

Utilisation de linter de contenu

Vous pouvez utiliser linter de contenu pour vérifier vos contributions en cas d’erreurs.

À propos de linter de contenu pour GitHub Docs

Notre linter de contenu applique des règles de guide de style dans notre contenu Markdown.

Le linter utilise markdownlint comme infrastructure pour effectuer des vérifications, signaler des défauts et corriger automatiquement le contenu, dans la mesure du possible. Cette infrastructure exécute de manière flexible des règles spécifiques, fournit des messages d’erreur descriptifs et corrige les erreurs. Le linter de contenu GitHub Docs utilise plusieurs règles existantes markdownlint et des règles personnalisées supplémentaires pour vérifier le contenu Markdown dans nos répertoires content etdata. Nos règles personnalisées implémentent des vérifications qui ne sont pas encore disponibles dans l’infrastructure markdownlint ou qui sont spécifiques au contenu GitHub Docs. Les règles vérifient la syntaxe pour Markdown et Liquid.

Exécution du linter de contenu GitHub Docs

Le linter de contenu GitHub Docs s’exécute automatiquement lors de la pré-validation, mais vous pouvez également l’exécuter manuellement.

Exécuter automatiquement linter lors de la pré-validation

Quand vous écrivez du contenu localement et que vous validez des fichiers à l’aide de la ligne de commande, ces fichiers mis en scène sont automatiquement lintés par le linter de contenu. Les avertissements et les erreurs sont signalés, mais seules les erreurs empêchent la fin de votre validation.

Si des erreurs sont signalées, votre validation ne se terminera pas. Vous devrez corriger les erreurs signalées, rajouter les fichiers modifiés et valider de nouveau vos modifications. Toutes les erreurs signalées doivent être corrigées pour empêcher l’introduction d’erreurs qui ne respectent pas le guide de style GitHub Docs dans le contenu. Si des avertissements sont signalés, vous pouvez éventuellement choisir de les corriger ou non.

Quand vous écrivez du contenu localement, il existe plusieurs règles que vous pouvez corriger automatiquement à l’aide de la ligne de commande. Si vous souhaitez corriger automatiquement les erreurs qui peuvent être corrigées, consultez « Corriger automatiquement les erreurs qui peuvent être corrigées ».

Si vous modifiez un fichier dans l’interface utilisateur GitHub, vous ne pourrez pas corriger automatiquement les erreurs ou exécuter le linter sur un engagement, mais vous obtiendrez un échec de CI si le contenu enfreint des règles avec une gravité de error.

Exécuter manuellement le linter

Exécuter le linter sur des fichiers intermédiaires et modifiés

Utilisez la commande suivante pour exécuter le linter localement sur vos fichiers intermédiaires et modifiés. Il génère les deux défauts graves, warning et error.

npm run lint-content

Exécuter le linter sur les fichiers intermédiaires et modifiés et signaler uniquement les erreurs

Utilisez la commande suivante pour exécuter le linter localement sur vos fichiers intermédiaires et modifiés et signalez uniquement les défauts graves error.

npm run lint-content -- --errors

Exécuter le linter sur des fichiers ou des répertoires spécifiques

Utilisez la commande suivante pour exécuter le linter localement sur des fichiers ou des répertoires spécifiques. Séparez plusieurs filtres par un espace. Vous pouvez inclure des fichiers et des répertoires dans la même commande.

Shell
npm run lint-content -- \
  --paths content/FILENAME.md content/DIRECTORY

Corriger automatiquement les erreurs qui peuvent être corrigées

Si une erreur a fixable: true dans sa description, vous pouvez utiliser les commandes suivantes pour les corriger automatiquement.

Exécutez cette commande pour corriger uniquement les fichiers intermédiaires et modifiés :

npm run lint-content -- --fix

Exécutez cette commande pour corriger des fichiers ou des répertoires spécifiques :

npm run lint-content -- \
  --fix --paths content/FILENAME.md content/DIRECTORY

Exécuter un ensemble spécifique de règles linter

Utilisez la commande suivante pour exécuter une ou plusieurs règles linter spécifiques. Ces exemples exécutent les règles heading-increment et code-fence-line-length. Remplacez heading-increment code-fence-line-length par un ou plusieurs alias linter que vous souhaitez exécuter. Pour afficher la liste des règles linter que vous pouvez passer à cette option, exécutez npm run lint-content -- --help. Vous pouvez utiliser le nom court (par exemple, MD001) ou le nom long (par exemple, heading-increment) d’une règle linter.

Exécutez les règles linter spécifiées sur tous les fichiers intermédiaires et modifiés :

npm run lint-content -- \
  --rules heading-increment code-fence-line-length

Exécutez les règles linter spécifiées sur des fichiers ou des répertoires spécifiques :

npm run lint-content -- \
  --rules heading-increment code-fence-line-length \
  --path content/FILENAME.md content/DIRECTORY

Contourner le hook de validation

Si le linter détecte des erreurs que vous n'avez pas introduites, vous pouvez contourner le hook de validation de git en utilisant l'--no-verifyoption lors de la validation de vos modifications.

git commit -m 'MESSAGE' --no-verify

Afficher le menu d’aide pour le script linter de contenu

npm run lint-content -- --help

Règles de linting

Chaque règle est configurée dans un fichier dans src/content-linter/style, où les gravités des règles sont définies.

Les erreurs doivent être traitées avant de fusionner vos modifications dans la branche main. Les avertissements doivent être traités, mais n’empêchent pas la fusion d’une modification dans la branche main. La plupart des règles seront finalement promues en erreurs, quand le contenu n’a plus de violations d’avertissement.

Identificateur de la règleNom(s) de la règleDescriptionGravitéBalises
MD001heading-incrementLes niveaux de titre ne doivent incrémenter qu’un seul niveau à la foiserrortitres
MD004ul-styleStyle de liste non ordonnéerrorpuce, ul
MD009no-trailing-spacesEspaces de finerrorwhitespace
MD011no-reversed-linksSyntaxe de lien inverséerrorliens
MD012no-multiple-blanksPlusieurs lignes vides consécutiveserrorespace blanc, blank_lines
MD014commands-show-outputLes signes dollar utilisés avant les commandes sans afficher la sortieerrorcode
MD018no-missing-space-atxAucun espace après hachage sur le titre de style atxerrortitres, atx, espaces
MD019no-multiple-space-atxPlusieurs espaces après hachage sur le titre de style atxerrortitres, atx, espaces
MD022blanks-around-headingsLes titres doivent être entourés de lignes videserrortitres, blank_lines
MD023heading-start-leftLes titres doivent commencer au début de la ligneerrortitres, espaces
MD027no-multiple-space-blockquotePlusieurs espaces après le symbole blockquoteerrorblockquote, espace blanc, retrait
MD029ol-prefixPréfixe d’élément de liste ordonnéerrorol
MD030list-marker-spaceEspaces après les marqueurs de listeerrorol, ul, espace blanc
MD031blanks-around-fencesLes blocs de code clôturés doivent être entourés de lignes videserrorcode, blank_lines
MD037no-space-in-emphasisEspaces à l’intérieur des marqueurs d’accentuationerrorespace blanc, accentuation
MD039no-space-in-linksEspaces à l’intérieur du texte du lienerrorespaces blancs, liens
MD040fenced-code-languageLes blocs de code délimités doivent avoir une langue spécifiéeerrorcode, langages
MD042no-empty-linksAucun lien videerrorliens
MD047single-trailing-newlineLes fichiers doivent se terminer par un caractère nouvelle ligne uniqueerrorblank_lines
MD049emphasis-styleStyle d’accentuationerroremphasis
MD050strong-styleStyle forterroremphasis
search-replacetodocs-placeholderInterceptez les occurrences de l’espace réservé TODOCS.error
search-replacedocs-domainInterceptez les occurrences de domaine docs.gitub.com.error
search-replacehelp-domainInterceptez les occurrences de domaine help.github.com.error
search-replacepreview-domainInterceptez les occurrences de domaine preview.ghdocs.com.error
search-replacedeveloper-domainInterceptez les occurrences de domaine developer.github.com.error
search-replacesyntaxe liquid déconseillée : site.dataInterceptez les occurrences de syntaxe de données liquid dépréciées.error
search-replacesyntaxe liquid déconseillée : octicon-La syntaxe liquid octicon utilisée est déconseillée. Utilisez ce format à la place octicon "<octicon-name>" aria-label="<Octicon aria label>"error
GH001no-default-alt-textLes images doivent avoir un texte de remplacement significatif (texte de remplacement)erroraccessibilité, images
GH002no-generic-link-textÉvitez d’utiliser du texte de lien générique comme Learn more ou Click hereerrorAccessibilité, liens
GHD030code-fence-line-lengthLes lignes délimitées de code ne doivent pas dépasser une longueur maximaleavertissementcode, accessibilité
GHD032image-alt-text-end-punctuationLe texte de remplacement des images doit se terminer par une ponctuationerroraccessibilité, images
GHD004image-file-kebab-caseLes noms de fichiers image doivent utiliser kebab-caseerrorimages
GHD033incorrect-alt-text-lengthLe texte de remplacement des images doit contenir entre 40 et 150 caractèresavertissementaccessibilité, images
GHD002internal-links-no-langLes liens internes ne doivent pas contenir de code de langage codé en durerrorliens, url
GHD003internal-links-slashLes liens internes doivent commencer par un /errorliens, url
GHD031image-alt-text-exclude-wordsLe texte de remplacement des images ne doit pas commencer par des mots tels que « image » ou « graphique »erroraccessibilité, images
GHD034list-first-word-capitalizationLe premier mot de l’élément de liste doit être capitaliséavertissementul, ol
GHD001link-punctuationLes titres de liens internes ne doivent pas contenir de ponctuationerrorliens, url
GHD008early-access-referencesLes fichiers qui ne sont pas en accès anticipé ne doivent pas référencer l’accès anticipé ou les fichiers d’accès anticipéerrorcaractéristiques, accès anticipé
GHD021yaml-scheduled-jobsLes extraits de code YAML qui incluent des flux de travail planifiés ne doivent pas s’exécuter à l’heure et doivent être uniqueserrorCaractéristiques, actions
GHD006internal-links-old-versionLes liens internes ne doivent pas contenir de version codée en dur à l’aide de l’ancienne syntaxe de contrôle de versionerrorliens, URL, contrôle de version
GHD005hardcoded-data-variableLes chaînes qui contiennent un « jeton d’accès personnel » doivent utiliser la variable de produit à la placeerrorsingle-source
GHD013github-owned-action-referencesLes références d’action appartenant à GitHub ne doivent pas être codées en durerrorCaractéristiques, actions
GHD016liquid-quoted-conditional-argLes balises conditionnelles liquid ne doivent pas citer l’argument conditionnelerrorliquid, format
GHD014liquid-data-references-definedLes données liquid ou les références de données mises en retrait ont été trouvées dans le contenu qui pourvu d’aucune valeur ou n’existent pas dans l’annuaire de donnéeserrorliquid
GHD015liquid-data-tag-formatLes balises de référence de données liquid ou de données mises en retrait doivent contenir le nombre correct d’arguments et d’espacementerrorliquid, format
GHD010frontmatter-hidden-docsLes articles ayant la propriété frontmatter hidden ne peuvent être situés que dans des produits spécifiqueserrorfrontmatter, caractéristiques, accès anticipé
GHD009frontmatter-early-access-referencesLes fichiers qui ne sont pas en accès anticipé ne doivent pas avoir de frontmatter qui référencent un accès anticipéerrorfrontmatter, caractéristiques, accès anticipé
GHD011frontmatter-video-transcriptsLa transcription vidéo doit être configurée correctementerrorfrontmatter, caractéristiques, transcriptions vidéo
GHD012frontmatter-schemaFrontmatter doit être conforme au schémaerrorfrontmatter, schéma
GHD007code-annotationsLes annotations de code définies dans Markdown doivent contenir une propriété frontmatter de disposition spécifiqueerrorcode, caractéristiques, annoter, frontmatter
GHD017frontmatter-liquid-syntaxLes propriétés frontmatter doivent utiliser liquid valideerrorliquid, frontmatter
GHD018liquid-syntaxLe contenu Markdown doit utiliser liquid valideerrorliquid
GHD019liquid-if-tagsLes balises liquid ifversion doivent être utilisées au lieu de balises if quand l’argument est une version valideerrorliquid, contrôle de version
GHD020liquid-ifversion-tagsLes balises liquid ifversion doivent contenir des noms de version valides en tant qu’argumentserrorliquid, contrôle de version
GHD022liquid-ifversion-versionsLiquid ifversion (et elsif) ne doit pas toujours être vraiavertissementliquid, contrôle de version
GHD035rai-reusable-usageLes articles et les éléments réutilisables RAI ne peuvent référencer que du contenu réutilisable dans le répertoire data/réutilisables/raierrorfeature, rai
GHD036image-no-gifL’image ne doit pas être un gif, référence du guide de style : contributing/style-guide-and-content-model/style-guide.md#imageserrorimages
GHD038expired-contentLe contenu expiré doit être corrigé.errorexpiré
GHD039expire bientôtLe contenu qui expire bientôt devrait être résolu de manière proactive.avertissementexpiré

Syntaxe des règles de linting

Certaines règles de linting retournent des avertissements ou des erreurs basés sur des commentaires HTML que vous pouvez ajouter à des articles.

Syntaxe pour l’expiration et l’expiration du contenu

Les règles GHD038 et GHD039 vérifient le contenu auquel une date d'expiration a été attribuée manuellement. Quatorze jours avant la date spécifiée, le linter de contenu renvoie un avertissement indiquant que le contenu expire bientôt. À compter de la date spécifiée, le linter de contenu retourne une erreur et signale le contenu pour la correction.

Vous pouvez ajouter une date d'expiration au contenu en l’encapsulant dans des balises HTML qui contiennent une date d'expiration au format :

<!-- expires yyyy-mm-dd --> <!-- end expires yyyy-mm-dd -->

Utiliser :

This content does not expire. <!-- expires 2022-01-28 -->This content expires on January 28, 2022. <!-- end expires 2022-01-28 -->This content also does not expire.

Suppression des règles de linter

Rarement, vous devrez peut-être documenter quelque chose qui enfreint une ou plusieurs règles de linter. Dans ces cas, vous pouvez supprimer des règles en ajoutant un commentaire au fichier Markdown. Vous pouvez désactiver toutes les règles ou règles spécifiques. Essayez toujours de limiter autant de règles que possible. Vous pouvez désactiver une règle pour un fichier entier, pour une section d’un fichier Markdown, une ligne spécifique ou la ligne suivante.

Par exemple, si vous écrivez un article qui inclut l’expression régulière (^|/)[Cc]+odespace/ qui examine la syntaxe des liens inversés, il déclenche la règle MD011 qui examine les liens inversés. Vous pouvez désactiver la règle MD011 sur cette ligne spécifique en ajoutant le commentaire suivant.

(^|/)[Cc]+odespace/ <!-- markdownlint-disable-line MD011 -->

Si la ligne que vous essayez d’ignorer se trouve dans un bloc de code, vous pouvez ignorer ce bloc de code en l’entourant des commentaires suivants.

<!-- markdownlint-disable MD011 -->
```
(^|/)[Cc]+odespace/
```
<!-- markdownlint-enable MD011 -->

Vous pouvez utiliser ces commentaires pour activer ou désactiver des règles.

CommentaireEffet
<!-- markdownlint-disable -->
Désactiver toutes les règles
<!-- markdownlint-enable -->
Activer toutes les règles
<!-- markdownlint-disable-line -->
Désactiver toutes les règles de la ligne actuelle
<!-- markdownlint-disable-next-line -->
Désactiver toutes les règles de la ligne suivante
<!-- markdownlint-disable RULE-ONE RULE-TWO -->
Désactiver une ou plusieurs règles par nom
<!-- markdownlint-enable RULE-ONE RULE-TWO -->
Activer une ou plusieurs règles par nom
<!-- markdownlint-disable-line RULE-NAME -->
Désactiver une ou plusieurs règles par nom pour la ligne active
<!-- markdownlint-disable-next-line RULE-NAME -->
Désactiver une ou plusieurs règles par nom pour la ligne suivante