Formatiert wird mit js-beautify, derselben Bibliothek, die in sehr vielen Editoren hinter dem Befehl zum Neuformatieren steckt — hier lokal mitgeliefert statt von irgendwoher geladen. Drei Modi stehen bereit: JavaScript, HTML und CSS, und das sind wirklich verschiedene Parser und nicht eine Routine mit einer Weiche. Deshalb ergibt der falsche Modus offensichtlich falsche Einrückung statt eines subtilen Fehlers.
Die Einrückung bestimmen Sie, in Leerzeichen oder Tabulatoren. Vorhandene Leerzeilen bleiben bis zu zwei aufeinanderfolgenden erhalten, der bewusste Abstand zwischen Funktionen überlebt also, während zufällige Häufungen aufgeräumt werden. Der Zeilenumbruch ist abgeschaltet, denn eine feste Umbruchspalte gerät meist in Konflikt mit dem, was das Projekt ohnehin tut.
Was Formatieren behebt und was nicht
-
Es formatiert um, es schreibt nicht um:
Keine Variable wird umbenannt, keine Anweisung umgestellt und keine Logik angefasst. Code, der vorher falsch war, ist es hinterher auch — nur übersichtlicher gesetzt.
-
Wählen Sie den Modus nach dem Inhalt, nicht nach der Dateiendung:
Eine Template-Datei voller Markup will den HTML-Modus, auch wenn ihr Name anderes nahelegt, und in eine Seite eingebettetes JavaScript wird vom HTML-Modus mitsamt allem drumherum formatiert.
-
Es ist kein Linter:
Nichts wird geprüft. Code, der sich nicht parsen lässt, meldet einen Fehler statt repariert zu werden, und Code, der zwar parst, aber fragwürdig ist, wird kommentarlos formatiert.
-
Ein Projekt mit eigenem Formatierer sollte diesen nutzen:
Prettier und ESLint tragen den vereinbarten Stil eines Projekts. Dies hier ist für ein Codestück von anderswo oder eine Datei ohne solche Einrichtung.
The same library behind a great many editors' reformat command
Formatting is handled by js-beautify, vendored locally rather than fetched from anywhere, which is the same library sitting behind the reformat command in a great many code editors. The [msm_tool slug="js-beautifier"] offers three modes — JavaScript, HTML and CSS — and they are genuinely separate parsers rather than one routine switching behaviour, which is why picking the wrong one produces indentation that is obviously wrong rather than subtly off.
It reformats, it does not rewrite
No variable is renamed, no statement is reordered, and no logic is touched at any point in the process. Code that was wrong before formatting is exactly as wrong afterwards — simply laid out more clearly, which makes the underlying problem easier to spot rather than fixing it automatically.
Choose the mode to match what was actually pasted
A template file full of markup wants the HTML mode even where its filename suggests otherwise, and JavaScript embedded directly inside a page gets formatted correctly by the HTML mode along with everything around it. The content in front of you, not the extension it happened to arrive with, is what should decide the mode.
It is not a linter
Nothing about the code is checked for correctness beyond whether it can be parsed at all. Code that fails to parse reports a failure rather than being repaired, and code that parses cleanly but is questionable in some other way is formatted exactly as given, without comment either way.
Why my code failed to format at all
A parse failure nearly always means a genuine syntax error somewhere in the source — an unclosed brace, bracket or string being the usual culprits. The formatter has no way to guess past a broken structure, so it reports the failure rather than attempting a repair that could easily make things worse.
Where a project's own formatter should win instead
Prettier and ESLint carry a project's specifically agreed style, and using this instead of either where one is already configured would fight against decisions the project has already made. This tool exists for a snippet arriving from somewhere else, or a file that has no formatting setup behind it at all.