Lint et formater automatiquement le code avant les commits

Discourse utilise lefthook pour les hooks git, et bin/lint comme point d’entrée principal de l’interface en ligne de commande pour exécuter manuellement les mêmes vérifications.

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

pnpm install
pnpm lefthook install

Ensuite, les fichiers mis en zone de préparation (staged) seront vérifiés automatiquement lors de 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, plutôt que d’attendre le hook pre-commit.

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

Rôle de chaque mode

  • bin/lint : linte tous les fichiers pris en charge dans le dépôt
  • bin/lint path/to/file ... : linte uniquement les fichiers spécifiés
  • bin/lint --recent : linte les fichiers modifiés lors des 50 derniers commits, ainsi que les fichiers non suivis (untracked)
  • bin/lint --staged : linte uniquement les fichiers mis en zone de préparation (staged)
  • bin/lint --unstaged : linte uniquement les fichiers non mis en zone de préparation (unstaged)
  • bin/lint --wip : linte les fichiers staged, les fichiers unstaged et les fichiers modifiés depuis la branche 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 sur l’ensemble du dépôt
  • bin/lint --verbose : affiche les commandes lefthook sous-jacentes

Lorsque vous transmettez des fichiers explicites, bin/lint les filtre selon les types de fichiers lintables pris en charge avant d’appeler lefthook.

:information_source: Les fichiers de documentation Markdown ne font actuellement pas partie de bin/lint, de sorte que l’exécution de bin/lint path/to/doc.md indiquera qu’aucun fichier correspondant n’est à linter.

Ce qui est linté

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)

Mise en forme de JavaScript, GJS, CSS et SCSS

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

Vérifications :

  • prettier/pprettier

Linting de JavaScript et GJS

  • frontend/**/*.{js,gjs}
  • Fichiers JS de plugins et de thèmes correspondants

Vérifications :

  • eslint (avec les règles template-* de eslint-plugin-ember couvrant la partie template des fichiers .gjs)

Linting de SCSS

  • app/assets/stylesheets/**/*.scss
  • Fichiers SCSS de plugins et de thèmes correspondants

Vérifications :

  • stylelint

Vérifications YAML et des localisations

  • **/*.{yaml,yml} à l’exception de config/database.yml
  • **/{client,server}.en.yml

Vérifications :

  • yaml-lint
  • script/i18n_lint.rb

Vérification des types

Lorsque vous exécutez bin/lint sans arguments de fichier, le lint complet du dépôt exécute également :

  • pnpm lint:types

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

:information_source: bin/lint path/to/file et le hook pre-commit n’exécutent pas la vérification de type complète. Utilisez bin/lint simple lorsque vous souhaitez un passage de lint complet sur tout le 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
  • 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
  • Linting i18n pour client.en.yml / server.en.yml
  • Vérification des types Glint

Relation avec les hooks git

Le hook pre-commit utilise la même configuration lefthook que bin/lint, mais il ne s’exécute que sur les fichiers mis en zone de préparation (staged).

Cela signifie :

  • un commit peut échouer si les fichiers staged ne passent pas le linting
  • bin/lint --staged est l’équivalent manuel le plus proche du hook pre-commit
  • bin/lint --fix --staged est un bon moyen de réparer exactement ce que vous êtes sur le point de commiter

Flux de travail pratique

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

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

# Vérifier exactement ce que le hook pre-commit vérifiera
bin/lint --staged

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

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

Ce document est sous contrôle de version - suggérez des modifications sur github.

11 « J'aime »

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