Linter et formater automatiquement le code avant les commits

Documentation Guides pour les développeurs
,
1

Discourse utilise lefthook pour les crochets git, et bin/lint comme point d’entrée CLI principal pour exécuter manuellement les mêmes vérifications.

Si vous travaillez dans un clone local, installez les hooks une fois :

pnpm install
pnpm lefthook install

Après cela, les fichiers préparés (staged) seront vérifiés automatiquement à git commit.

La commande principale : bin/lint

Utilisez bin/lint lorsque vous souhaitez exécuter vous-même les linters configurés du dépôt au lieu d’attendre le crochet de pré-validation (pre-commit hook).

Exemples courants :

bin/lint
bin/lint path/to/file.rb path/to/file.gjs
bin/lint --recent
bin/lint --staged
bin/lint --unstaged
bin/lint --wip
bin/lint --fix path/to/file.rb
bin/lint --fix --recent
bin/lint --fix

Ce que fait chaque mode

  • bin/lint : effectue l’analyse syntaxique de tous les fichiers pris en charge dans le dépôt
  • bin/lint path/to/file ... : effectue l’analyse syntaxique uniquement des fichiers donnés
  • bin/lint --recent : effectue l’analyse syntaxique des fichiers modifiés dans les 50 derniers commits, plus les fichiers non suivis
  • bin/lint --staged : effectue l’analyse syntaxique uniquement des fichiers préparés
  • bin/lint --unstaged : effectue l’analyse syntaxique uniquement des fichiers non préparés
  • bin/lint --wip : effectue l’analyse syntaxique des fichiers préparés, des fichiers non préparés et des fichiers modifiés depuis main
  • bin/lint --fix ... : exécute les correcteurs automatiques pour les fichiers sélectionnés
  • bin/lint --fix : exécute tous les correcteurs automatiques disponibles dans le dépôt
  • bin/lint --verbose : affiche les commandes lefthook sous-jacentes

Lorsque vous fournissez des fichiers explicites, bin/lint les filtre pour n’inclure que les types de fichiers pris en charge pour l’analyse syntaxique avant d’invoquer lefthook.

:information_source: Les fichiers de documentation Markdown ne font pas actuellement partie de bin/lint, donc l’exécution de bin/lint path/to/doc.md signalera qu’aucun fichier correspondant n’a été trouvé pour l’analyse.

Ce qui est analysé

La configuration exacte se trouve dans lefthook.yml. Au moment de la rédaction, bin/lint couvre :

Ruby

  • **/*.{rb,rake,thor}
  • Scripts Ruby sous bin/**/*
  • Gemfile

Vérifications :

  • rubocop
  • syntax_tree (stree check)

Formatage JavaScript, GJS, CSS et SCSS

  • app/assets/stylesheets/**/*.{css,scss}
  • frontend/**/*.{js,gjs,scss,css,cjs,mjs}
  • fichiers d’actifs de thème et de plugin correspondants

Vérifications :

  • prettier/pprettier

Analyse syntaxique JavaScript et GJS

  • frontend/**/*.{js,gjs}
  • fichiers JS de thème et de plugin correspondants

Vérifications :

  • eslint

Analyse syntaxique de modèles GJS

  • frontend/**/*.gjs
  • fichiers .gjs de thème et de plugin correspondants

Vérifications :

  • ember-template-lint

Analyse syntaxique SCSS

  • app/assets/stylesheets/**/*.scss
  • fichiers SCSS de thème et de plugin correspondants

Vérifications :

  • stylelint

Vérifications YAML et de localisation

  • **/*.{yaml,yml} sauf config/database.yml
  • **/{client,server}.en.yml

Vérifications :

  • yaml-lint
  • script/i18n_lint.rb

Vérification de type (Type checking)

Lorsque vous exécutez bin/lint sans arguments de fichier, l’analyse syntaxique complète du dépôt s’exécute également :

  • pnpm lint:types

Il s’agit de la vérification de style Glint/TypeScript pour les informations de type JavaScript de Discourse.

:information_source: bin/lint path/to/file et le crochet de pré-validation ne lancent pas la vérification de type complète. Utilisez simplement bin/lint lorsque vous souhaitez une analyse syntaxique complète à l’échelle du dépôt.

Ce qui peut être corrigé automatiquement

bin/lint --fix peut corriger automatiquement de nombreux problèmes, mais pas tous.

La correction automatique est configurée pour :

  • prettier --write
  • eslint --fix
  • ember-template-lint --fix
  • stylelint --fix
  • rubocop -A
  • syntax_tree (stree write)

En pratique, cela signifie que --fix peut reformater et réécrire :

  • Ruby
  • JavaScript / GJS
  • CSS / SCSS

Ces vérifications ne sont pas corrigées automatiquement par bin/lint --fix :

  • Validation de la syntaxe YAML
  • Analyse syntaxique i18n pour client.en.yml / server.en.yml
  • Vérification de type / Glint

Relation avec les crochets git

Le crochet de pré-validation utilise la même configuration lefthook que bin/lint, mais il s’exécute uniquement sur les fichiers préparés (staged).

Cela signifie :

  • un commit peut échouer parce que les fichiers préparés ne passent pas l’analyse syntaxique
  • bin/lint --staged est l’équivalent manuel le plus proche du crochet de pré-validation
  • bin/lint --fix --staged est un bon moyen de réparer exactement ce que vous êtes sur le point de commettre

Flux de travail pratique

Pour le développement quotidien, voici les commandes les plus utiles :

# Avant de commettre quelques fichiers modifiés
bin/lint --fix path/to/file1.rb path/to/file2.gjs

# Vérifier exactement ce que le crochet de pré-validation va vérifier
bin/lint --staged

# Nettoyer tout le travail en cours
bin/lint --fix --wip

# Exécuter la suite d'analyse syntaxique complète du dépôt, y compris les vérifications de type
bin/lint

Ce document est contrôlé par version - suggérez des modifications sur github.

11 « J'aime »
Two tracked variables not updating
2

7 messages ont été déplacés vers un nouveau sujet : Débogage du linting sur Discourse