Linter 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

Après cela, les fichiers ajoutés à l’index (staged) seront automatiquement vérifiés lors de git commit.

La commande principale : bin/lint

Utilisez bin/lint lorsque vous souhaitez exécuter vous-même les linters configurés dans le dépôt, au lieu 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

Ce que fait 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 dans les 50 derniers commits, ainsi que les fichiers non suivis
  • bin/lint --staged : linte uniquement les fichiers ajoutés à l’index (staged)
  • bin/lint --unstaged : linte uniquement les fichiers non ajoutés à l’index (unstaged)
  • bin/lint --wip : linte les fichiers staged, 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 passez des fichiers explicites, bin/lint les filtre selon les types de fichiers lintables pris en charge avant d’appeler lefthook.

:information_source: Les fichiers Markdown ne sont lintés que sous docs/developer-guides/. L’exécution de bin/lint path/to/doc.md sur tout autre fichier Markdown indiquera qu’aucun fichier n’a été linté.

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 JavaScript, GJS, CSS et SCSS

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

Vérifications :

  • prettier/pprettier

Linting JavaScript et GJS

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

Vérifications :

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

Linting SCSS

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

Vérifications :

  • stylelint

Vérifications YAML et locales

  • **/*.{yaml,yml} sauf 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 style Glint/TypeScript pour les informations de type de Discourse. Elle s’exécute en mode strict de TypeScript et génère également les déclarations publiées.

:information_source: bin/lint path/to/file et le hook pre-commit n’exécutent pas la vérification complète des types. Utilisez simplement bin/lint si 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 beaucoup de 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/type

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 ajoutés à l’index (staged).

Cela signifie :

  • un commit peut échouer parce que les fichiers staged ne passent pas le lint
  • 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 committer

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 hook pre-commit vérifiera
bin/lint --staged

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

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

Ce document est versionné - suggérer des modifications sur github.

11 « J'aime »

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