JavaScript-Formatierer

Prettier ist nicht bloß die Inspiration für die Formatierungsausgabe dieses Tools — es ist das Prettier-Paket selbst, in Ihren Browser heruntergeladen und statt über Node auf einem Server ausgeführt, daher ist das Ergebnis byteidentisch zu dem, was das lokale Ausführen von `npx prettier` mit derselben Konfiguration erzeugen würde. Diese Unterscheidung ist wichtig, weil JavaScript-Formatierung wirklich schwer zu approximieren ist: Es korrekt zu machen erfordert, die Sprache vollständig zu analysieren, nicht sie gegen Muster abzugleichen, und ein Formatierer, der nur Prettiers Verhalten approximiert, wird von der echten Prettier-Konfiguration eines Projekts genau in den Randfällen abweichen, wo es wichtig ist — innerhalb eines Dekorators, eines komplexen generischen Typs, oder eines ungewöhnlichen JSX-Ausdrucks.

JavaScript enthält mehrere Konstrukte, die einen einfachen Ansatz aus Klammer- und Semikolonzählen direkt scheitern lassen. Template-Literale können beliebigen Text zwischen Backticks enthalten, einschließlich Zeichen, die exakt wie Code aussehen — `` `function() { return "not real code"; }` `` ist ein einzelner Zeichenkettenwert, keine drei Anweisungen, und ein Formatierer, der die Grenzen von Template-Literalen nicht verfolgt, wird das falsch interpretieren. Reguläre-Ausdruck-Literale sind schlimmer: `/{}/` enthält Zeichen, die wie geschweifte Klammern aussehen, aber Teil des Musters des regulären Ausdrucks selbst sind, keine strukturelle Syntax. Automatische Semikolon-Einfügung fügt eine dritte Schwierigkeitsebene hinzu, da JavaScript erlaubt, Semikolons in vielen Kontexten wegzulassen, und ableitet, wo eine Anweisung endet, nach Regeln, die ein naiver zeilenbasierter Formatierer nicht korrekt reproduzieren kann. Die Sprache wirklich in einem angemessenen Syntaxbaum zu analysieren, wie Prettier es tut, ist es, was alle drei Fehlermodi vermeidet — ein Abkürzungs-Formatierer, der selbst bei einem davon in Produktionscode falsch liegt, ist ein Risiko, keine Bequemlichkeit.

Prettier formatiert Code — standardisiert Leerzeichen, Zeilenumbrüche, Anführungszeichenstil und ähnliche Darstellungsentscheidungen — und prüft explizit nicht, ob der Code korrekt, typsicher oder fehlerfrei ist. Eine Datei mit einem Typfehler, einer Referenz auf eine undefinierte Variable, oder einem logischen Fehler wird ohne Beschwerde formatiert, solange sie syntaktisch gültig ist, weil Formatieren und Typprüfung getrennte, von getrennten Werkzeugen behandelte Anliegen sind. Der TypeScript-Compiler selbst, oder ein Linter wie ESLint, ist, wo Korrektheit geprüft wird; die Arbeit dieses Tools endet damit, Code konsistent und lesbar zu gestalten.

Tabs versus Leerzeichen, einfache versus doppelte Anführungszeichen, Semikolon oder nicht — keine dieser Entscheidungen beeinflusst wesentlich, wie der Code läuft, und Uneinigkeiten darüber verbrauchten früher echte Zeit in Code-Review-Diskussionen, die nichts mit Korrektheit zu tun hatten. Der eigentliche Wertvorschlag von Prettier ist, diese Debatte komplett vom Tisch zu nehmen: Ein kleiner, meinungsstarker Satz von Formatierungsregeln, automatisch und überall identisch angewendet, bedeutet, dass die Debatte einmal in der Konfiguration entschieden wird, statt sich bei jedem Pull Request danach zu wiederholen.

Jede hier verfügbare Option — Einrückungsbreite, Semikolons, Anführungszeichenstil — spiegelt eine echte Prettier-Konfigurationseinstellung wider, daher reproduziert das Einfügen von Code aus einem Projekt mit bekannter `.prettierrc` und das Abgleichen derselben Einstellungen hier exakt das, was das eigene Tool dieses Projekts erzeugen würde, ohne dass Sie lokal irgendetwas installieren müssen, nur um zu prüfen, wie ein Fragment formatiert würde.