Kontext der Arbeit
In unserem Projektteam gelten strenge Lint-Regeln, die sogar die Sortierung von Importen erzwingen.
Obwohl dies den Vorteil einer einheitlichen Codestilgestaltung mit sich bringt, kam es ab und zu vor, dass nach der Erstellung eines PRs in der CI Lint-Fehler auftraten.
Auch wenn dies nicht häufig vorkam, bedeutete ein Lint-Fehler, dass man lokal ein Skript ausführen musste, um die Fehler zu korrigieren, die Änderungen zu committen und dann erneut zu pushen.
Dieser lästige Prozess war einer der Hauptgründe für die Verlängerung der Codereview-Zeiten. Deshalb schlug ich den anderen Teammitgliedern vor, einen Lint-Check in den pre-push Hook einzubauen.
Nach Zustimmung der Teammitglieder und unter Verwendung des bereits vorhandenen lint-fix:global
Skripts erstellte ich folgenden pre-push Hook:
echo "🔍 Ausführen des Lint Fix..."
pnpm run lint-fix:global
# Überprüfung auf Änderungen
if ! git diff --quiet; then
echo "❌ Beim Linting wurden einige Dateien korrigiert. Bitte die Änderungen vor dem Pushen committen."
exit 1
fi
Doch am nächsten Tag erhielt ich folgendes Feedback. Einige von Ihnen erkennen das Problem sofort:

Unabhängig von der Ausführung von lint-fix:global
schlug der Git Push fehl, wenn einige Dateien im staged Zustand belassen wurden. 🤦
Schließlich kam ich zu dem Schluss, dass das einfache Überprüfen auf Lint-Fehler ausreichender ist als ein Lint Fix, und änderte den Code wie folgt:
echo "🔍 Ausführen des Lints..."
if ! pnpm run lint -- --quiet; then
echo "❌ Lint-Fehler erkannt."
echo "👉 Um Fehler automatisch zu beheben: pnpm run lint-fix:global"
exit 1
fi
Das in obigem Code ausgeführte lint
Skript ist tatsächlich das Skript für next lint
.
Indem die --quiet
Option hinzugefügt wurde, werden nur Fehler angezeigt, die bei Auftreten zur Ausgabe einer Fehlermeldung und Blockierung des Pushes führen.
Für meine Teammitglieder habe ich außerdem die Fehlermeldungen etwas freundlicher gestaltet.
Ich hoffe, dass wir in Zukunft keine Zeit mehr mit Lint-Fehlern in der CI verschwenden müssen. 🙏