Code automatisch vor Commits linteren und formatieren

[Discourse]

Discourse verwendet lefthook für Git-Hooks und bin/lint als Haupteinstiegspunkt der CLI, um dieselben Prüfungen manuell auszuführen.

Wenn du in einem lokalen Clone arbeitest, installiere die Hooks einmalig:

pnpm install
pnpm lefthook install

Danach werden gestagte Dateien automatisch bei git commit geprüft.

Der Hauptbefehl: bin/lint

Verwende bin/lint, wenn du die konfigurierten Linter des Repositories selbst ausführen möchtest, anstatt auf den Pre-Commit-Hook zu warten.

Häufige Beispiele:

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

Was jeder Modus bewirkt

• bin/lint: Lintet alle unterstützten Dateien im Repository
• bin/lint path/to/file ...: Lintet nur die angegebenen Dateien
• bin/lint --recent: Lintet Dateien, die in den letzten 50 Commits geändert wurden, sowie nicht verfolgte Dateien
• bin/lint --staged: Lintet nur gestagte Dateien
• bin/lint --unstaged: Lintet nur nicht gestagte Dateien
• bin/lint --wip: Lintet gestagte Dateien, nicht gestagte Dateien und Dateien, die seit main geändert wurden
• bin/lint --fix ...: Führt die Auto-Fixer für die ausgewählten Dateien aus
• bin/lint --fix: Führt alle verfügbaren Auto-Fixer im gesamten Repository aus
• bin/lint --verbose: Gibt die zugrunde liegenden lefthook-Befehle aus

Wenn du explizite Dateien übergibst, filtert bin/lint diese vor dem Aufruf von lefthook auf unterstützte Lint-Dateitypen.

Markdown-Dokumentationsdateien sind derzeit nicht Teil von bin/lint. Das Ausführen von bin/lint path/to/doc.md meldet daher, dass keine passenden Dateien zum Linten gefunden wurden.

Was gellt wird

Die genaue Konfiguration befindet sich in lefthook.yml. Zum Zeitpunkt des Schreibens deckt bin/lint Folgendes ab:

Ruby

• **/*.{rb,rake,thor}
• Ruby-Skripte unter bin/**/*
• Gemfile

Prüfungen:

• rubocop
• syntax_tree (stree check)

Formatierung von JavaScript, GJS, CSS und SCSS

• app/assets/stylesheets/**/*.{css,scss}
• frontend/**/*.{js,gjs,scss,css,cjs,mjs}
• entsprechende Plugin- und Theme-Asset-Dateien

Prüfungen:

• prettier/pprettier

Linting von JavaScript und GJS

• frontend/**/*.{js,gjs}
• entsprechende Plugin- und Theme-JS-Dateien

Prüfungen:

• eslint (mit den template-*-Regeln von eslint-plugin-ember, die den Template-Teil von .gjs-Dateien abdecken)

Linting von SCSS

• app/assets/stylesheets/**/*.scss
• entsprechende Plugin- und Theme-SCSS-Dateien

Prüfungen:

• stylelint

YAML- und Locale-Prüfungen

• **/*.{yaml,yml} außer config/database.yml
• **/{client,server}.en.yml

Prüfungen:

• yaml-lint
• script/i18n_lint.rb

Typprüfung

Wenn du bin/lint ohne Dateiparameter ausführst, wird zusätzlich das vollständige Repo-Linting mit Folgendem durchgeführt:

• pnpm lint:types

Dies ist die Glint-/TypeScript-ähnliche Prüfung für die Typinformationen von JavaScript in Discourse.

bin/lint path/to/file und der Pre-Commit-Hook führen nicht die vollständige Typprüfung aus. Verwende das einfache bin/lint, wenn du den vollständigen lint-Durchlauf für das gesamte Repository durchführen möchtest.

Was automatisch behoben werden kann

bin/lint --fix kann viele Probleme automatisch beheben, aber nicht alle.

Auto-Fix ist konfiguriert für:

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

In der Praxis bedeutet das, dass --fix Folgendes neu formatieren und umschreiben kann:

• Ruby
• JavaScript / GJS
• CSS / SCSS

Diese Prüfungen werden nicht von bin/lint --fix automatisch behoben:

• YAML-Syntaxvalidierung
• i18n-Linting für client.en.yml / server.en.yml
• Glint/Typprüfung

Beziehung zu Git-Hooks

Der Pre-Commit-Hook verwendet dieselbe lefthook-Konfiguration wie bin/lint, führt die Prüfung jedoch nur gegen gestagte Dateien durch.

Das bedeutet:

• Ein Commit kann fehlschlagen, weil gestagte Dateien das Linting nicht bestehen
• bin/lint --staged ist das engste manuelle Äquivalent zum Pre-Commit-Hook
• bin/lint --fix --staged ist eine gute Möglichkeit, genau das zu reparieren, was du gleich committen wirst

Praktischer Arbeitsablauf

Für die tägliche Entwicklung sind diese Befehle am nützlichsten:

# Bevor ein paar geänderte Dateien committet werden
bin/lint --fix path/to/file1.rb path/to/file2.gjs

# Überprüfen, was genau der Pre-Commit-Hook prüfen wird
bin/lint --staged

# Alle aktuellen Arbeiten im Gange aufräumen
bin/lint --fix --wip

# Den vollständigen Repo-Lint-Suite ausführen, einschließlich Typprüfungen
bin/lint

---

Dieses Dokument wird versioniert – schlage Änderungen auf GitHub vor.