Hooks führen Shell-Befehle an festen Punkten einer Sitzung aus: nachdem eine Datei geschrieben wurde, bevor ein Werkzeug läuft, wenn ein Zug endet. Sie sind der einzige Teil der Konfiguration, der Code ausführt, ohne jedes Mal zu fragen, und deshalb lohnt es, ihre stillen Fehler zu jagen. Ein Matcher, der ein nicht existierendes Werkzeug nennt, feuert nie und beschwert sich nie. Ein Befehl, der nach einem Argument greift, bekommt eine leere Zeichenkette, denn das Ereignis kommt als JSON über die Standardeingabe und nicht als Argumente. Und nur manche Ereignisse können wirklich verhindern, was gleich passiert wäre. Dieser Builder deckt alle drei Fälle ab und sagt, welche Ereignisse blockieren und welche nur beobachten.
Funktionen
Jedes Ereignis mit dem, worauf es feuert
Matcher gegen echte Werkzeugnamen geprüft, Groß- und Kleinschreibung inklusive
Warnt bei einem Matcher an einem Ereignis ohne Werkzeug
Warnt, wenn ein Befehl nach Argumenten greift, die er nie bekommt
Sagt, welche Ereignisse eine Aktion blockieren können — und wie
Gängige Matcher-Muster als Ein-Klick-Vorlagen
Mehrere Hooks korrekt nach Ereignis und Matcher gruppiert
Markiert einen zerstörerischen Befehl, bevor er unbeaufsichtigt läuft
So verwendest du Hooks-Builder
Wählen Sie das Ereignis, auf das Sie reagieren wollen
Ergänzen Sie einen Matcher, wenn das Ereignis werkzeugspezifisch ist
Schreiben Sie den Befehl und lesen Sie die Nutzlast von der Standardeingabe
Lesen Sie die Warnungen und übernehmen Sie die Ausgabe in settings.json
Beispiel
Eingabe
prettier --write "$1"
Ausgabe
Warning: $1 will be empty — a hook is not given arguments
Das Ereignis kommt als JSON über die Pipe; lesen Sie es mit jq.
Häufige Fehler & Fehlerbehebung
Der Hook läuft nie. — Meist der Matcher. Werkzeugnamen sind großgeschrieben und schreibungssensitiv — Write, nicht write — und ein nicht existierender Name passt still zu nichts.
Der Befehl läuft, bekommt aber keine Eingabe. — Die Hook-Eingabe kommt als JSON über die Standardeingabe. Lesen Sie sie etwa mit jq -r '.tool_input.file_path', statt ein Argument zu erwarten.
Mein Hook kann den Aufruf nicht stoppen. — Nur manche Ereignisse können das, und nur mit Exit-Status 2. Alles andere heißt „weitermachen“, und Ereignisse wie PostToolUse feuern ohnehin danach.
Die Sitzung hängt an meinem Hook. — Setzen Sie ein Zeitlimit. Ein Hook, der auf etwas wartet — einen Netzwerkaufruf, eine Sperre — hält die ganze Sitzung auf.
Häufig gestellte Fragen
Welches Ereignis nehme ich für einen Formatter?
PostToolUse mit einem Matcher für die schreibenden Werkzeuge, damit er läuft, wenn die Datei existiert. Vor dem Schreiben zu formatieren hat nichts zu formatieren.
Wie erhält der Hook das Ereignis?
Als JSON über die Standardeingabe: der Werkzeugname, seine Eingabe und der Kontext. Nichts wird als Kommandozeilenargument übergeben, und deshalb bekommt ein um $1 herum geschriebener Befehl nichts.
Kann ein Hook ein Werkzeug am Laufen hindern?
Vor dem Lauf ja: Exit-Status 2 blockiert. Welche Ereignisse das erlauben, wird bei der Auswahl angezeigt, denn der Versuch, aus einem nachgelagerten Ereignis zu blockieren, ist ein ebenso häufiger wie verwirrender Fehler.
Laufen Hooks ohne Rückfrage?
Ja — das ist ihr Sinn und der Grund, jeden Hook vor dem Hinzufügen genau zu lesen. Ein Hook, der Dateien löscht, wird hier markiert; die allgemeine Regel bleibt, dass alles in dieser Datei unbeaufsichtigt läuft.
Kann ich mehrere Hooks an einem Ereignis haben?
Ja. Hooks mit gleichem Ereignis und Matcher werden in der Ausgabe gruppiert — genau die Form, die die Konfigurationsdatei erwartet.