Optionen

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Prettier bietet eine Handvoll Formatierungsoptionen.

Mehr zu Prettiers Philosophie bezüglich Optionen erfahren Sie unter Option Philosophy.

Wenn Sie Optionen ändern, empfehlen wir dies über eine Konfigurationsdatei zu tun. So wissen Prettier CLI, Editor-Integrationen und andere Tools, welche Optionen Sie verwenden.

Experimentelle Ternäre

Testen Sie Prettiers neue Ternär-Formatierung, bevor sie Standardverhalten wird.

Gültige Optionen:

• true - Verwendet "curious ternaries" mit dem Fragezeichen hinter der Bedingung.

• false - Behält Standardverhalten bei: Fragezeichen bleiben in derselben Zeile wie die Konsequenz.

Default	CLI Override	API Override
false	--experimental-ternaries	experimentalTernaries: <bool>

Experimentelle Operator-Position

Gültige Optionen:

• "start" - Platziert Operatoren bei Zeilenumbrüchen am Anfang neuer Zeilen.

• "end" - Standardverhalten: Operatoren bleiben bei Zeilenumbrüchen am Ende vorheriger Zeilen.

Default	CLI Override	API Override
"end"	--experimental-operator-position <start|end>	experimentalOperatorPosition: "<start|end>"

Zeilenlänge

Legt die Zeilenlänge fest, an der der Printer Umbricht.

Warnung

Aus Gründen der Lesbarkeit raten wir von über 80 Zeichen ab:

In Code-Styleguides werden Zeilenlängen oft auf 100-120 Zeichen begrenzt. Entwickler streben jedoch nicht bei jeder Zeile nach der maximalen Zeichenzahl. Durch Leerzeichen werden lange Zeilen zur besseren Lesbarkeit gebrochen, sodass die Durchschnittslänge meist deutlich unter dem Maximum liegt.

Prettiers printWidth-Option funktioniert anders. Sie ist kein hartes Limit, sondern gibt eine Richtgröße für die gewünschte Zeilenlänge vor. Prettier erzeugt sowohl kürzere als auch längere Zeilen, strebt aber generell die angegebene printWidth an.

Denken Sie daran: Computer benötigen explizite Anweisungen, während Menschen implizite Entscheidungen treffen können, z.B. wann eine Zeile umgebrochen wird.

Anders gesagt: Verwenden Sie printWidth nicht wie ESLints max-len – sie sind nicht identisch. max-len definiert nur die maximale Zeilenlänge, nicht die bevorzugte Länge – was printWidth vorgibt.

Default	CLI Override	API Override
80	--print-width <int>	printWidth: <int>

Die Einstellung von max_line_length in einer .editorconfig-Datei konfiguriert Prettiers Zeilenlänge, sofern nicht überschrieben.

(Wenn Sie bei Markdown-Formatierung keinen Zeilenumbruch wünschen, deaktivieren Sie dies über die Prose Wrap-Option.)

Tab-Breite

Legt die Anzahl der Leerzeichen pro Einrückungsebene fest.

Default	CLI Override	API Override
2	--tab-width <int>	tabWidth: <int>

Die Einstellung von indent_size oder tab_width in einer .editorconfig-Datei konfiguriert Prettiers Tab-Breite, sofern nicht überschrieben.

Tabs

Verwendet Tabs statt Leerzeichen für Einrückungen.

Default	CLI Override	API Override
false	--use-tabs	useTabs: <bool>

Die Einstellung von indent_style in einer .editorconfig-Datei konfiguriert Prettiers Tab-Verwendung, sofern nicht überschrieben.

(Tabs werden für Einrückungen verwendet, während Prettier Leerzeichen zur Ausrichtung nutzt, z.B. bei Ternären. Dieses Verhalten ist als SmartTabs bekannt.)

Semikolons

Fügt Semikolons am Ende von Anweisungen ein.

Gültige Optionen:

• true - Fügt jeder Anweisung ein Semikolon hinzu.

• false - Fügt Semikolons nur am Anfang von Zeilen ein, die ASI-Fehler verursachen können.

Default	CLI Override	API Override
true	--no-semi	semi: <bool>

Anführungszeichen

Verwenden Sie einfache statt doppelter Anführungszeichen.

Hinweise:

• JSX-Anführungszeichen ignorieren diese Option – siehe jsx-single-quote.

• Wenn eine Art von Anführungszeichen häufiger vorkommt, wird das weniger verwendete für die Formatierung genutzt – Beispiel: "I'm double quoted" bleibt "I'm double quoted" und "This \"example\" is single quoted" wird zu 'This "example" is single quoted'.

Weitere Informationen finden Sie in der Begründung für Strings.

Default	CLI Override	API Override
false	--single-quote	singleQuote: <bool>

Anführungszeichen bei Eigenschaften

Legt fest, wann Eigenschaften in Objekten in Anführungszeichen gesetzt werden.

Gültige Optionen:

• "as-needed" - Setzt Anführungszeichen nur bei Eigenschaften, die sie benötigen.

• "consistent" - Wenn mindestens eine Eigenschaft Anführungszeichen benötigt, erhalten alle Eigenschaften welche.

• "preserve" - Behält die vorhandene Verwendung von Anführungszeichen bei.

Default	CLI Override	API Override
"as-needed"	--quote-props <as-needed|consistent|preserve>	quoteProps: "<as-needed|consistent|preserve>"

Hinweis: Prettier entfernt niemals Anführungszeichen bei numerischen Eigenschaftsnamen in Angular-Ausdrücken, TypeScript und Flow, da der Unterschied zwischen String- und numerischen Schlüsseln in diesen Sprachen bedeutsam ist. Siehe: Angular, TypeScript, Flow. Außerdem entfernt Prettier bei Vue keine Anführungszeichen bei numerischen Eigenschaften (siehe Issue).

JSX-Anführungszeichen

Verwenden Sie einfache statt doppelter Anführungszeichen in JSX.

Default	CLI Override	API Override
false	--jsx-single-quote	jsxSingleQuote: <bool>

Nachgestellte Kommas

Standardwert wurde in v3.0.0 von es5 auf all geändert

Fügt nachgestellte Kommas ein, wo immer möglich in mehrzeiligen, kommagetrennten syntaktischen Strukturen. (Ein einzeiliges Array erhält beispielsweise nie nachgestellte Kommas.)

Gültige Optionen:

• "all" - Nachgestellte Kommas, wo immer möglich (einschließlich Funktionsparametern und -aufrufen). Für die Ausführung benötigt JavaScript-Code in diesem Format eine Engine mit ES2017-Unterstützung (Node.js 8+ oder moderner Browser) oder Downlevel-Kompilierung. Ermöglicht auch nachgestellte Kommas bei Typparametern in TypeScript (unterstützt seit TypeScript 2.7, veröffentlicht Januar 2018).

• "es5" - Nachgestellte Kommas, wo in ES5 gültig (Objekte, Arrays etc.). Nachgestellte Kommas bei Typparametern in TypeScript und Flow.

• "none" - Keine nachgestellten Kommas.

Default	CLI Override	API Override
"all"	--trailing-comma <all|es5|none>	trailingComma: "<all|es5|none>"

Abstände zwischen Klammern

Setzt Leerzeichen zwischen Klammern in Objektliteralen.

Gültige Optionen:

• true - Beispiel: { foo: bar }.

• false - Beispiel: {foo: bar}.

Default	CLI Override	API Override
true	--no-bracket-spacing	bracketSpacing: <bool>

Objektumbruch

Erstmals verfügbar in v3.5.0

Konfiguriert, wie Prettier Objektliterale umbricht, wenn sie in eine Zeile passen oder sich über mehrere Zeilen erstrecken.

Standardmäßig formatiert Prettier Objekte als mehrzeilig, wenn vor der ersten Eigenschaft ein Zeilenumbruch steht. Autoren können diese Heuristik nutzen, um die Lesbarkeit kontextuell zu verbessern, obwohl sie einige Nachteile hat. Siehe Mehrzeilige Objekte.

Gültige Optionen:

• "preserve" - Behält mehrzeilige Formatierung bei, wenn zwischen der öffnenden Klammer und der ersten Eigenschaft ein Zeilenumbruch steht.

• "collapse" - Fügt, wenn möglich, in eine einzelne Zeile.

Default	CLI Override	API Override
"preserve"	--object-wrap <preserve|collapse>	objectWrap: "<preserve|collapse>"

Klammerzeile

Setzt das > eines mehrzeiligen HTML-Elements (HTML, JSX, Vue, Angular) am Ende der letzten Zeile, anstatt allein in der nächsten Zeile zu stehen (gilt nicht für selbstschließende Elemente).

Gültige Optionen:

• true - Beispiel:

<button
  className="prettier-class"
  id="prettier-id"
  onClick={this.handleClick}>
  Click Here
</button>

• false - Beispiel:

<button
  className="prettier-class"
  id="prettier-id"
  onClick={this.handleClick}
>
  Click Here
</button>

Default	CLI Override	API Override
false	--bracket-same-line	bracketSameLine: <bool>

[Veraltet] JSX-Klammern

Gefahr

Diese Option ist seit v2.4.0 veraltet, verwenden Sie stattdessen --bracket-same-line.

Setzt das > eines mehrzeiligen JSX-Elements am Ende der letzten Zeile, anstatt allein in der nächsten Zeile zu stehen (gilt nicht für selbstschließende Elemente).

Gültige Optionen:

• true - Beispiel:

<button
  className="prettier-class"
  id="prettier-id"
  onClick={this.handleClick}>
  Click Here
</button>

• false - Beispiel:

<button
  className="prettier-class"
  id="prettier-id"
  onClick={this.handleClick}
>
  Click Here
</button>

Default	CLI Override	API Override
false	--jsx-bracket-same-line	jsxBracketSameLine: <bool>

Klammern bei Pfeilfunktionen

Erstmals verfügbar in v1.9.0, Standardwert wurde in v2.0.0 von avoid zu always geändert

Fügt Klammern um den einzigen Parameter einer Pfeilfunktion ein.

Gültige Optionen:

• "always" - Immer Klammern einfügen. Beispiel: (x) => x

• "avoid" - Klammern weglassen, wenn möglich. Beispiel: x => x

Default	CLI Override	API Override
"always"	--arrow-parens <always|avoid>	arrowParens: "<always|avoid>"

Auf den ersten Blick scheint das Weglassen von Klammern wegen weniger visueller Unruhe die bessere Wahl zu sein.
Wenn Prettier jedoch Klammern entfernt, wird es schwieriger, Typannotationen, zusätzliche Argumente oder Standardwerte hinzuzufügen sowie andere Änderungen vorzunehmen.
Durchgängige Verwendung von Klammern bietet eine bessere Entwicklererfahrung beim Bearbeiten echter Codebasen, was den Standardwert für die Option rechtfertigt.

Bereich

Formatiert nur einen Abschnitt einer Datei.

Diese beiden Optionen können verwendet werden, um Code ab einem bestimmten Zeichen-Offset (inklusiv) und bis zu einem bestimmten Zeichen-Offset (exklusiv) zu formatieren. Der Bereich erstreckt sich:

• Rückwärts bis zum Anfang der ersten Zeile, die die ausgewählte Anweisung enthält.

• Vorwärts bis zum Ende der ausgewählten Anweisung.

Default	CLI Override	API Override
0	--range-start <int>	rangeStart: <int>
Infinity	--range-end <int>	rangeEnd: <int>

Parser

Gibt an, welcher Parser verwendet werden soll.

Prettier leitet den Parser automatisch aus dem Eingabedateipfad ab, daher sollten Sie diese Einstellung nicht ändern müssen.

Sowohl die Parser babel als auch flow unterstützen denselben Satz an JavaScript-Funktionen (einschließlich Flow-Typannotationen). Sie können in einigen Randfällen unterschiedlich sein. Wenn Sie auf einen solchen Fall stoßen, können Sie flow anstelle von babel ausprobieren. Fast dasselbe gilt für typescript und babel-ts. babel-ts unterstützt möglicherweise JavaScript-Funktionen (Vorschläge), die TypeScript noch nicht unterstützt, ist jedoch weniger nachsichtig bei ungültigem Code und weniger erprobt als der typescript-Parser.

Gültige Optionen:

• "babel" (über @babel/parser) Bis Version 1.16.0 als "babylon" bezeichnet

• "babel-flow" (wie "babel", aktiviert aber explizit Flow-Parsing zur Vermeidung von Mehrdeutigkeit) Erstmals verfügbar in Version 1.16.0

• "babel-ts" (ähnlich wie "typescript", nutzt jedoch Babel und dessen TypeScript-Plugin) Erstmals verfügbar in Version 2.0.0

• "flow" (über flow-parser)

• "typescript" (über @typescript-eslint/typescript-estree) Erstmals verfügbar in Version 1.4.0

• "espree" (über espree) Erstmals verfügbar in Version 2.2.0

• "meriyah" (über meriyah) Erstmals verfügbar in Version 2.2.0

• "acorn" (über acorn) Erstmals verfügbar in Version 2.6.0

• "css" (über postcss) Erstmals verfügbar in Version 1.7.1

• "scss" (über postcss-scss) Erstmals verfügbar in Version 1.7.1

• "less" (über postcss-less) Erstmals verfügbar in Version 1.7.1

• "json" (über @babel/parser parseExpression) Erstmals verfügbar in Version 1.5.0

• "json5" (wie "json", gibt jedoch json5 aus) Erstmals verfügbar in Version 1.13.0

• "jsonc" (wie "json", gibt jedoch "JSON mit Kommentaren" aus) Erstmals verfügbar in Version 3.2.0

• "json-stringify" (wie "json", gibt jedoch wie JSON.stringify aus) Erstmals verfügbar in Version 1.13.0

• "graphql" (über graphql/language) Erstmals verfügbar in Version 1.5.0

• "markdown" (über remark-parse) Erstmals verfügbar in Version 1.8.0

• "mdx" (über remark-parse und @mdx-js/mdx) Erstmals verfügbar in Version 1.15.0

• "html" (über angular-html-parser) Erstmals verfügbar in Version 1.15.0

• "vue" (wie "html", formatiert aber auch vue-spezifische Syntax) Erstmals verfügbar in Version 1.10.0

• "angular" (wie "html", formatiert aber auch angular-spezifische Syntax über angular-estree-parser) Erstmals verfügbar in Version 1.15.0

• "lwc" (wie "html", formatiert aber auch LWC-spezifische Syntax für unquotierte Template-Attribute) Erstmals verfügbar in Version 1.17.0

• "mjml" (gleicher Parser wie "html", formatiert aber auch MJML-spezifische Syntax) Erstmals verfügbar in 3.6.0

• "yaml" (über yaml und yaml-unist-parser) Erstmals verfügbar in 1.14.0

Default	CLI Override	API Override
None	--parser <string>	parser: "<string>"

Hinweis: Der Standardwert war "babylon" bis Version 1.13.0.

Hinweis: Die Custom Parser API wurde in Version 3.0.0 entfernt. Verwenden Sie stattdessen Plugins (Migrationsanleitung).

Dateipfad

Geben Sie den Dateinamen an, um den zu verwendenden Parser abzuleiten.

Das folgende Beispiel verwendet beispielsweise den CSS-Parser:

cat foo | prettier --stdin-filepath foo.css

Diese Option ist nur in der CLI und API sinnvoll. Für Konfigurationsdateien ist sie nicht geeignet.

Default	CLI Override	API Override
None	--stdin-filepath <string>	filepath: "<string>"

Pragma erforderlich

Erstmals verfügbar in v1.7.0

Prettier kann sich auf Dateien beschränken, die einen speziellen Kommentar (Pragma genannt) am Dateianfang enthalten. Dies ist besonders nützlich bei der schrittweisen Migration großer, unformatierter Codebasen zu Prettier.

Eine Datei mit folgendem Kommentar am Anfang wird formatiert, wenn --require-pragma angegeben wird:

/**
 * @prettier
 */

oder

/**
 * @format
 */

Default	CLI Override	API Override
false	--require-pragma	requirePragma: <bool>

Pragma einfügen

Pragma einfügen

Prettier kann einen speziellen @format-Marker am Anfang von Dateien einfügen, der angibt, dass die Datei mit Prettier formatiert wurde. Dies funktioniert gut in Kombination mit der Option --require-pragma. Wenn bereits ein Docblock am Anfang der Datei vorhanden ist, fügt diese Option eine neue Zeile mit dem @format-Marker hinzu.

Beachten Sie, dass "im Zusammenspiel" nicht "gleichzeitig" bedeutet. Bei gleichzeitiger Verwendung hat --require-pragma Priorität, sodass --insert-pragma ignoriert wird. Die Idee ist, dass während der schrittweisen Prettier-Einführung in großen Codebasen teilnehmende Entwickler --insert-pragma verwenden, während --require-pragma vom Rest des Teams und automatisierten Tools genutzt wird, um nur bereits migrierte Dateien zu verarbeiten. Das Feature wurde von Facebooks Adoptionsstrategie inspiriert.

Default	CLI Override	API Override
false	--insert-pragma	insertPragma: <bool>

Ignorieren-Pragma prüfen

Erstmals verfügbar in v3.6.0

Prettier kann einzelne Dateien von der Formatierung ausschließen, wenn sie einen speziellen Kommentar (Pragma genannt) am Dateianfang enthalten.

Die Überprüfung dieser Marker verursacht geringe Laufzeiteinbußen bei der Formatierung und ist daher standardmäßig deaktiviert.

Eine Datei mit folgendem Kommentar am Anfang wird nicht formatiert, wenn --check-ignore-pragma angegeben wird:

/**
 * @noprettier
 */

oder

/**
 * @noformat
 */

Default	CLI Override	API Override
false	--check-ignore-pragma	checkIgnorePragma: <bool>

Fließtextumbruch

Textumbruch

Standardmäßig ändert Prettier den Zeilenumbruch in Markdown-Text nicht, da einige Dienste zeilenumbruchsensitive Renderer verwenden (z.B. GitHub-Kommentare und BitBucket). Um Text automatisch an der Druckbreite umbrechen zu lassen, setzen Sie diese Option auf "always". Um Textblöcke stattdessen in einer Zeile zu belassen und auf Softwrapping im Editor/Viewer zu vertrauen, verwenden Sie "never".

Gültige Optionen:

• "always" - Text umbrechen, wenn die Druckbreite überschritten wird.

• "never" - Jeden Textblock in eine einzelne Zeile schreiben.

• "preserve" - Keine Änderungen, Text unverändert belassen. Erstmals verfügbar in v1.9.0

Default	CLI Override	API Override
"preserve"	--prose-wrap <always|never|preserve>	proseWrap: "<always|never|preserve>"

Leerzeichenempfindlichkeit in HTML

Erstmals verfügbar in v1.15.0. Für Handlebars erstmals verfügbar in v2.3.0

Legt die globale Empfindlichkeit auf Leerzeichen für HTML, Vue, Angular und Handlebars fest. Weitere Informationen finden Sie unter Formatierung bei Leerzeichen mit Bedeutung.

Gültige Optionen:

• "css" - Respektiert den Standardwert der CSS-display-Eigenschaft. Für Handlebars wie strict behandelt.

• "strict" - Leerzeichen (oder deren Fehlen) um alle Tags wird als signifikant betrachtet.

• "ignore" - Leerzeichen (oder deren Fehlen) um alle Tags wird als insignifikant betrachtet.

Default	CLI Override	API Override
"css"	--html-whitespace-sensitivity <css|strict|ignore>	htmlWhitespaceSensitivity: "<css|strict|ignore>"

Einrückung von script- und style-Tags in Vue-Dateien

Erstmals verfügbar in v1.19.0

Legt fest, ob Code innerhalb von <script>- und <style>-Tags in Vue-Dateien eingerückt werden soll.

Gültige Optionen:

• false - Script- und style-Tags in Vue-Dateien nicht einrücken.

• true - Script- und style-Tags in Vue-Dateien einrücken.

Default	CLI Override	API Override
false	--vue-indent-script-and-style	vueIndentScriptAndStyle: <bool>

Zeilenende

Erstmals verfügbar in v1.15.0, Standardwert in v2.0.0 von auto zu lf geändert

Historisch bedingt existieren zwei gängige Zeilenendungsvarianten in Textdateien: \n (oder LF für Line Feed) und \r\n (oder CRLF für Carriage Return + Line Feed).
Erstere ist unter Linux und macOS üblich, letztere dominiert unter Windows.
Hintergründe hierzu finden Sie auf Wikipedia.

Bei kollaborativer Arbeit über verschiedene Betriebssysteme hinweg können gemischte Zeilenenden in Git-Repositories auftreten.
Windows-Nutzer können versehentlich Zeilenenden in committeten Dateien von LF zu CRLF ändern, was umfangreiche git diffs erzeugt und die zeilenweise Historie (git blame) erschwert.

So stellen Sie sicher, dass Ihr Git-Repository nur Linux-konforme Zeilenenden in Prettier-bearbeiteten Dateien enthält:

1. Setzen Sie Prettiers endOfLine-Option auf lf (Standardwert seit v2.0.0)

2. Richten Sie einen Pre-Commit-Hook für Prettier ein

3. Integrieren Sie Prettier mit --check-Flag in Ihre CI-Pipeline. Bei Travis CI setzen Sie die autocrlf-Option in .travis.yml auf input.

4. Fügen Sie * text=auto eol=lf zur .gitattributes-Datei des Repos hinzu.
   Windows-Nutzer müssen das Repo nach dieser Änderung neu klonen, um Konvertierungen von LF zu CRLF beim Checkout zu vermeiden.

Moderne Texteditoren aller Betriebssysteme zeigen \n (LF) korrekt an.
Ältere Notepad-Versionen für Windows komprimieren solche Zeilen jedoch visuell, da sie nur \r\n (CRLF) verarbeiten.

Gültige Optionen:

• "lf" – Nur Line Feed (\n), üblich unter Linux/macOS und in Git-Repos

• "crlf" - Carriage Return + Line Feed-Zeichen (\r\n), häufig unter Windows

• "cr" - Nur Carriage Return-Zeichen (\r), sehr selten verwendet

• "auto" - Bestehende Zeilenenden beibehalten (gemischte Werte in einer Datei werden normalisiert, indem geschaut wird, was nach der ersten Zeile verwendet wird)

Default	CLI Override	API Override
"lf"	--end-of-line <lf|crlf|cr|auto>	endOfLine: "<lf|crlf|cr|auto>"

Die Einstellung von end_of_line in einer .editorconfig-Datei konfiguriert Prettiers Zeilenende-Verwendung, sofern nicht überschrieben.

Formatierung eingebetteter Sprachen

Erstmals verfügbar in v2.1.0

Steuert, ob Prettier in Anführungszeichen eingebetteten Code innerhalb der Datei formatiert.

Wenn Prettier Fälle erkennt, in denen Code, den es formatieren kann, innerhalb einer Zeichenkette platziert wurde – wie in getaggten Templates in JavaScript mit einem Tag namens html oder in Codeblöcken in Markdown –, versucht es standardmäßig, diesen Code zu formatieren.

Manchmal ist dieses Verhalten unerwünscht, besonders wenn nicht beabsichtigt war, dass die Zeichenkette als Code interpretiert wird. Diese Option ermöglicht das Umschalten zwischen Standardverhalten (auto) und kompletter Deaktivierung (off).

Gültige Optionen:

• "auto" – Formatiert eingebetteten Code, wenn Prettier ihn automatisch identifizieren kann.

• "off" – Formatiert eingebetteten Code niemals automatisch.

Default	CLI Override	API Override
"auto"	--embedded-language-formatting=<off|auto>	embeddedLanguageFormatting: "<off|auto>"

Ein Attribut pro Zeile

Erstmals verfügbar in v2.6.0

Erzwingt ein Attribut pro Zeile in HTML, Vue und JSX.

Gültige Optionen:

• false – Erzwingt kein Attribut pro Zeile.

• true – Erzwingt ein Attribut pro Zeile.

Default	CLI Override	API Override
false	--single-attribute-per-line	singleAttributePerLine: <bool>