Skip to main content

JavaScript-Formatierer / Minimierer

JavaScript-Code mit Prettier-artigen Standardeinstellungen formatieren, verschonern und minimieren.

Geprüft von · Zuletzt geprüft

Den JavaScript-Formatierer verwenden

  1. Füge deinen Quellcode ein in den Eingabebereich. Einfaches JavaScript, TypeScript, ES-Module, CommonJS oder ein minimiertes Bundle, das von einem CDN heruntergeladen wurde, werden alle akzeptiert.
  2. Wähle einen Einzug: 2 Leerzeichen (Airbnb- und Prettier-Standard), 4 Leerzeichen (ältere Node-Konventionen) oder Tabulatoren.
  3. Drücke Formatieren, um den Quellcode mit richtiger Einrückung um geschweifte Klammern und eckige Klammern zu umbrechen, oder Minimieren, um den Code auf das kleinste Byte-Zahl-Äquivalent zu komprimieren.
  4. Kopieren oder weiter iterieren. Der Ausgabebereich behält das letzte Ergebnis, sodass du zwischen Formatieren und Minimieren auf demselben Buffer hin- und herschaltest, ohne den Zustand zu verlieren.

Wie der Formatierer funktioniert

Die Implementierung verwendet musterbasierte Transformationen statt eines vollständigen ECMAScript-Parsers. Sie verfolgt drei Kontexte während des Scannens: innerhalb eines String-Literals (einfach, doppelt oder Template), innerhalb eines Regular-Expression-Literals und innerhalb eines Block- oder Zeilen-Kommentars. Außerhalb dieser Bereiche erhöht eine öffnende geschweifte Klammer oder eckige Klammer einen Einrückungszähler und fügt einen Zeilenumbruch ein; eine schließende geschweifte Klammer oder eckige Klammer dekrementiert und gibt einen Zeilenumbruch davor aus. Semikolons an Anweisungsgrenzen erzeugen Zeilenumbrüche, sodass jede Anweisung auf ihrer eigenen Zeile endet.

Der Minimierer tut das Gegenteil: Leerzeichenläufe werden zu einem einzelnen Leerzeichen reduziert oder dort entfernt, wo Javascripts automatische Semikolon-Einfügungsregeln (ASI) es erlauben, und alle Zeilen- und Block-Kommentare werden entfernt. Weil der Formatierer kein echter Parser ist, benennt er keine Bezeichner um, eliminiert keinen toten Code und wendet nicht die Dutzenden von größensparenden Transformationen an, die ein Produktionswerkzeug wie Terser oder esbuild hätte. Seine Aufgabe sind Lesbarkeits-Hin-und-Rücktransporte, keine Build-Time-Optimierung. Dieser Kompromiss bedeutet auch, dass das Werkzeug TypeScript, JSX, Decoratoren und Stage-3-Vorschläge toleriert, die einen strengen ECMAScript-Parser brechen würden.

Typische Szenarien

  • Ein minimiertes Vendor-Skript aus einem node_modules-Bundle lesen, um die Quelle eines Produktionsfehlers zu finden.
  • Einen Code-Ausschnitt für einen Blog-Post, README oder ein internes Wiki vorbereiten, wo der Einzug dem Projektstil-Guide entsprechen muss.
  • Kommentare aus einem Ausschnitt entfernen, bevor er extern geteilt wird, um TODOs oder interne IDs zu entfernen.
  • Die Ausgabe eines Codegen-Werkzeugs (Nexus, GraphQL Code Generator) normalisieren, dessen Leerzeichen zwischen Laufen variiert.
  • Einen eingebetteten Analytics-Snippet komprimieren, der in einen <script>-Tag auf einer Seite ohne Build-Schritt eingefügt wird.
  • Schnell zwischen Tabulatoren und Leerzeichen konvertieren, wenn du ein Repository mit einer fremden Editor-Konfiguration klonst.

Fallstricke, die du kennen solltest

  • ASI-Gefahren. JavaScript fügt Semikolons an Zeilenumbrüchen nur in bestimmten Kontexten ein. Das Minimieren von Code, der auf implizite Semikolons angewiesen ist und eine Zeile mit [, ( oder / beginnt, kann seine Bedeutung ändern. Wenn deine Quelle ohne Semikolons ist (Standard.js-Stil), füge diesen Zeilen ein führendes Semikolon hinzu, bevor du minimierst.
  • Template-Literale mit verschachtelten Ausdrucken. ${'${'}...}-Interpolationen werden verbatim bewahrt, weil der Tokenizer die Template-Literal-Tiefe verfolgt, aber tief verschachtelte Templates können in der Ausgabe ungewohnliche Einruckungen erhalten.
  • Regex vs. Division. Ohne einen echten Parser können a / b und a / b /g mehrdeutig sein. Das Werkzeug verwendet einfache Heuristiken (vorheriges Token muss ein Wert für Division sein) und behandelt die häufigen Fälle, aber obskurer Code kann eine Regex falsch lesen.
  • JSX. JSX übersteht einen Hin-und-Rücktransport, erhält aber keine React-bewusste Einrückung (Attribute auf separaten Zeilen, selbstschließendes am Ende). Verwende Prettier für Produktions-JSX.
  • Source Maps. Das Minimieren hier erzeugt keine Source Map. Wenn du Stacktraces auf Originalzeilen zeigen brauchst, minimiere während deines Build-Schritts mit Terser und behalte die .map-Datei.

Hintergrund zur JavaScript-Sprache

JavaScript ist als ECMAScript standardisiert, jährlich von Ecma International als ECMA-262 veröffentlicht. Die aktuelle Ausgabe zum Zeitpunkt der Erstellung ist ES2024. Die Sprache ist leerzeichen-unempfindlich, außer für einige Regeln: automatische Semikolon-Einfügung an bestimmten Token-Grenzen, eingeschränkte Produktionen (z.B. kann kein Zeilenumbruch zwischen return und dem zurückgegebenen Ausdruck stehen) und das zeilenumbruch-sensitive Verhalten von ++ und --. Deshalb vermeidet dieses Werkzeug das Umschreiben von Dingen, die ASI beeinflussen könnten, und deshalb behält der Minimierer Semikolons statt sich auf implizite zu verlassen. TypeScript ist eine von Microsoft gepflegte Obermenge; seine Typannotationen werden vor der Ausführung gelöscht und sind daher sicher als Klartext durch einen Text-Level-Formatierer zu bewahren.

Kompatibilitat mit Prettier-Standardeinstellungen

Der Online-JavaScript-Formatierer zielt auf Prettiers Standardstil, sodass in ein Prettier-gesteuertes Repository eingefügte Ausgabe beim nächsten Lint-Durchlauf idempotent bleibt. Diese Standardeinstellungen sind: 2-Leerzeichen-Einrückung, Semikolons nach Anweisungen, doppelte Anführungszeichen nur wenn der String ein einfaches Anführungszeichen enthält (sonst einfache Anführungszeichen), nachlaufende Kommas in mehrzeiligen Arrays und Objekten und ein 80-Zeichen-Druckbreiten-Hinweis für Zeilenumbrüche. Diese Standardeinstellungen beizubehalten entspricht dem, was npx prettier --write mit einem Zero-Config-Setup produzieren würde, was die häufigste Konfiguration über Open-Source-Repos hinweg ist. Wenn dein Team eine davon in einem .prettierrc überschreibt, führe Prettier lokal nach diesem Werkzeug aus, um die beiden abzugleichen.

Unterschied zu Prettier, ESLint und Terser

Prettier erstellt einen vollständigen AST mit Babel und gibt Code nach einem meinungsstarken Stilführer neu aus - handhabt Zeilenlängen-Limits, nachlaufende Kommas und konsistente Anführungszeichen. Führe Prettier in deinem Repository aus; es produziert immer ein besseres Ergebnis für ernsthafte Formatierung. eslint --fix führt regelgesteuerte Auto-Korrekturen aus (unbenutzte Importe, var-zu-let). Terser oder esbuild --minify führen semantisches Minimieren durch: mangling von Bezeichnern, Wegfall von totem Code, Falten von Konstanten. Diese erfordern einen echten Parser und Vertrauen in die Korrektheit des Codes. Dieses In-Browser-Werkzeug ist für den spezifischen Fall gedacht, in dem du keines davon installieren kannst (oder möchtest) - ein einzelnes minimiertes Snippet lesen, ein einzeiliges Beispiel für Dokumentation vorbereiten oder schnell eine Wegwerf-Datei verkleinern.

Häufig gestellte Fragen

Verwendet das Prettier oder Babel intern?

Nein. Es liefert einen kleinen Regex- und Zustandsmaschinen-basierten Formatierer mit etwa 3 KB JavaScript. Deshalb lädt die Seite sofort und funktioniert nach dem ersten Besuch offline. Das bedeutet auch, dass die Ausgabe weniger poliert ist als die von Prettier, das deinen Code in einen vollständigen AST mit Babel parst und dann nach Dutzenden von abgestimmten Regeln ausgibt. Für teamweite Formatierung installiere Prettier; für einmalige Inspektion reicht dieses Werkzeug.

Kann es TypeScript-Typannotationen verarbeiten?

Ja, weil der Formatierer auf Token-Ebene operiert, anstatt einen TypeScript-Parser auszuführen. Typannotationen, Generics wie <code>Array&lt;string&gt;</code>, Enum-Deklarationen und Decorator-Syntax überstehen alle einen Hin- und Rücktransport. Was er nicht tut, ist die Korrektheit der Annotationen zu verifizieren; führe dafür lokal <code>tsc --noEmit</code> aus. Er entfernt auch keine Typen beim Minimieren - er behandelt sie als einfache Token, was eine kleinere, aber immer noch typisierte Datei ergibt.

Warum bricht mein minimierter Code gelegentlich, wenn er woanders eingefügt wird?

JavaScript hat einige Stellen, an denen Leerzeichen und Zeilenumbrüche semantisch bedeutsam sind. Insbesondere können Zeilen, die mit <code>(</code>, <code>[</code> oder <code>/</code> nach einer semikolon-losen Zeile beginnen, als Fortsetzung des vorherigen Ausdrucks neu interpretiert werden. Wenn du den ASI-Stil (keine expliziten Semikolons) verwendest, füge diesen Zeilen ein führendes <code>;</code> hinzu, bevor du minimierst, oder führe die Originaldatei durch ein Build-Werkzeug, das ASI korrekt behandelt.

Wird mein Code während der Verarbeitung an einen Server gesendet?

Nein. Die Format- und Minimier-Schaltflächen sind mit lokalen JavaScript- Funktionen im Seiten-Bundle verdrahtet. Es gibt keine Netzwerkanfrage an ein Backend, keine WebSocket-Verbindung und keine Speicherung in IndexedDB. Du kannst den Netzwerk-Tab in DevTools öffnen und bestätigen, dass kein ausgehender Datenverkehr generiert wird, wenn du auf eine der Schaltflächen klickst. Die Eingabe und Ausgabe liegen im JavaScript- Speicher und werden beim Schließen des Tabs verworfen.

Wie verhält es sich im Vergleich zu einfügen-und-als-Prettier-zu-speichern?

Ein In-Editor-Prettier-Lauf ist strikt besser für die Korrektheit, weil er deinen Code parst, erfordert aber ein funktionierendes Node-Setup und dein Repository mit konfiguriertem Prettier. Dieses Werkzeug ist es wert, wenn du auf einem Gerät ohne Node bist, wenn du schnell ein gebundeltes Vendor-Skript inspizieren möchtest, oder wenn die Quelle nicht Teil irgendeines Projekts ist und du es einfach lesbar haben möchtest. Betrachte es als ergänzend, nicht als Ersatz.

Was passiert mit JSX-Code?

JSX-Token überstehen den Tokenizer. Ein Element wie <code>&lt;Button onClick={handle}&gt;Go&lt;/Button&gt;</code> wird intakt hin- und zurücktransportiert, aber du bekommst nicht das React-idiomatische Verhalten, lange Attributlisten uber mehrere Zeilen zu brechen oder schließende Klammern auszurichten. Prettiers JSX-Behandlung ist wesentlich ausgefeilter; verwende es für Produktions-React-Code.

Kann ich eine ganze große Datei formatieren?

Ja, innerhalb der Grenzen deines Browser-Tabs. Dateien unter etwa einem Megabyte formatieren in deutlich unter einer Sekunde. Darüber blockiert der Single-Thread-Tokenizer den UI-Thread für einige Sekunden. Wenn du regelmäßig so große Dateien formatierst, ist die eigentliche Antwort, Prettier als Pre-Commit-Hook zu übernehmen, damit niemand die unformatierte Datei überhaupt eincheckt.

Bewahrt es Kommentare oder streicht es sie?

Formatieren bewahrt alle Kommentare (Zeilen- und Block-) und platziert Block-Kommentare auf ihren eigenen Zeilen. Minimieren streicht Kommentare vollständig, einschließlich Lizenz-Banner. Das Werkzeug behandelt derzeit <code>/*! */</code>-Bang-Kommentare, die Lizenzierungs-Pipelines verwenden, um Urheberrechtshinweise zu bewahren, nicht speziell - wenn das wichtig ist, extrahiere diese Kommentare vor dem Minimieren oder verwende Terser mit seiner <code>preserveComments</code>-Option.

Was ist mit modernen Funktionen wie optionalem Verkettungsoperator oder Top-Level-await?

Sie werden bewahrt, weil der Tokenizer sich nicht um Semantik kümmert. Optionaler Verkettungsoperator (<code>a?.b</code>), Nullish-Coalescing (<code>a ?? b</code>), logische Zuweisungsoperatoren und Top-Level- <code>await</code> überstehen alle. Das Werkzeug warnt dich nicht, wenn eine Ziel-Runtime (älteres Node, älteres Safari) sie nicht unterstützt; verwende <code>@babel/preset-env</code> oder einen zielorientierten esbuild-Build dafür.

Warum Semikolons beim Minimieren behalten statt auf ASI zu vertrauen?

Explizite Semikolons machen die minimierte Ausgabe robust gegenuber dem Verbinden mit anderen Dateien oder dem Inlinen in HTML, wo Formatierung sich andern kann. Auf ASI zu vertrauen spart eine Handvoll Bytes pro tausend Zeilen, führt aber eine echte Klasse von Fehlern ein, wenn die Ausgabe mit anderem Code kombiniert wird. Produktions-Bundler wie Terser geben aus demselben Grund standardmäßig Semikolons aus.

Verwandte Tools

Mehr Developer Tools

ZeroUtil unterstützen