|

🗂 Kapitel-Übersicht

Teil 1: Was ist Prettier? Und warum sollte ich es verwenden?

Teil 2: Vom Installationsprozess bis zum Produktiveinsatz.

➡️ Teil 3: Optionen und Individualisierungsmöglichkeiten

Im letztem Teil dieser dreiteiligen Serie "Make it 🎀Prettier" geht es um einige Formatierungstricks und sämtliche Optionen, die Prettier zur Anpassung der Formatierungsregeln anbietet.

Wie in den vorherigen Teilen bereits erwähnt, verändert Prettier nur die Formatierung von Code und dies möglichst nach einheitlichen Standards.
Dennoch ist es möglich, einige Regeln in der .prettierrc-Konfigurationsdatei anzupassen.
Bitte beachtet aber, dass jede Abweichung vom Prettier-Standard sich von dem eigentlichen Ziel von Prettier weg bewegt.

Aber kommen wir zunächst zu den Formatierungsmöglichkeiten direkt im Code, die ohne Konfiguration schon gewisse Freiheiten erlauben.

Mehrzeilige Objekte

Wenn nach der öffnenden { Klammer eine neue Zeile kommt, wird das Objekt mehrzeilig, 🔎 Details.

Bsp:

const user = {
  name: "bitspeicher", id: 42
};

wird zu:

const user = {
  name: "bitspeicher",
  id: 42
};

während

const user = {  name: "bitspeicher",
	id: 42
};

umgewandelt wird in

const blog = { name: "bitspeicher", id: 42 };

Dateien oder einzelne Zeilen ignorieren

Um komplette Dateien zu ignorieren, schreibt man deren Pfad in die .prettierignore im root-Verzeichnis (ähnlich wie bei einer .gitignore).

Um aber nur einen Code-Abschnitt einer Datei nicht formatieren zu lassen, verwenden wir einen Kommentar mit dem Text prettier-ignore. Dieser Kommentar lässt Prettier den nachfolgenden Code-Abschnitt beim Formatieren der Datei überspringen.

Ein Beispiel:

matrix(
  1, 3, 3, 7,
  0, 4, 2, 0,
  1, 3, 3, 7
)

wird standardmäßig zu

matrix(1, 3 , 3 , 7 ,0 , 4 , 2 , 0 , 1 , 3 , 3 , 7);

Dies kann verhindert werden durch

// prettier-ignore
matrix(
  1, 3, 3, 7,
  0, 4, 2, 0,
  1, 3, 3, 7
)

Weitere Beispiele finden sich in den Docs.

Solche ignore-Kommentare gibt es für diverse Dateiformate in verschiedenen Ausführungen:

Häufigste Anwendungsfälle:

js: // prettier-ignore

html: <!-- prettier-ignore -->

(sc|sa|c)ss: /* prettier-ignore */

md: <!-- prettier-ignore -->

! Wichtig Nur weil es möglich ist, sollten diese Tricks nicht genutzt werden. Wie in Teil 1 erwähnt, versucht Prettier, dem Anwender die Formatierungsentscheidungen abzunehmen. Klar gibt es Sonderfälle, aber in der Regel /sollte/ man sich besser zweimal fragen, ob ein fragliches Stück Code jetzt wirklich nicht formatiert werden darf.

Denkt daran: Je näher an Prettiers Vorgaben, umso einheitlicher der Code.

Optionen

Auch, wenn Prettier nicht gerade viele Optionen bietet und jede Option sich weiter von dem Ziel, einheitliche Formatierungen zu liefern entfernt, sind aufgrund des Alters und der Vielfalt von JavaScript zum Beispiel einige Optionen verfügbar:

Einrückung und Umbruch

--print-width maximale Zeilenlänge 🔎 Details

--tab-width Anzahl an Whitespaces pro Einrückung 🔎 Details

--use-tabs verwende Tabs anstatt Leerzeichen 🔎 Details

Zeichensetzung

--no-semi keine Semicolons am Ende jedes Statements setzen.

🔎 Doc Details 🔎 Explanation Details

--single-quote bevorzuge einfache Anführungszeichen.

Bei komplexen Verschachtelungen wird die bestmögliche Option (wir erinnern uns, opinionated formating) verwendet.

🔎 Details

--trailing-comma ermöglicht die einfache Verwendung von trailing commas, sprich abschließenden Kommata.
Da das Feature erst seit ES2017 (ES8) unterstützt wird, ermöglicht diese Option die Verwendung, wenn kein Transpiler wie z.B. Babel verwendet wird.

let arr = [
  1, 
  2, 
  3, <--
];

🔎 Details

--arrow-parens sollen bei Arrow-Functions mit nur einem Wert Klammern gesetzt werden? Diese Option erleichtert Refactoring und kann Kompatibilitätsprobleme mit ESLint beheben.

a => {} //default

vs.

(a) => {}

🔎 Details

--prose-wrap löst diverse Markdown-Umbruch-Probleme mit Git-Kommentaren oder mit BitBucket. 🔎 Details

--html-whitespace-sensitivity löst HTML-Whitespace-Probleme.
Standardmäßig werden die Standard-CSS display Eigenschaften eines Tags zur Formatierung bevorzugt genutzt.
🔎 Details 🔎 Explanation Details

--end-of-line verhindert CRLFs in Git-Projekten.
Oder in verständlich: Es sorgt dafür, dass keine ungewollten Darstellungsfehler durch verschiedene Zeilenenden durch unterschiedliche Plattformen in Git-Projekten entstehen.
🔎 Details

Sonstige

Diese Regeln existieren, sollten aber entweder für die meisten Nutzer nicht benötigt werden (Sonderregelungen für Frameworks wie React) oder sogar vermieden (existieren nur aus Kompatibilitätsgründen) werden.

--jsx-single-quote 🔎 Details

--jsx-bracket-same-line 🔎 Details

--range-start und --range-end 🔎 Details

--parser 🔎 Details

--stdin-filepath 🔎 Details

--bracket-spacing 🔎 Details

--require-pragma, --insert-pragma 🔎 Details

Das waren nun alle Optionen, die Prettier bietet.
Wenn mein Plan aufgeht, solltest du jetzt alle Infos haben, die du benötigst, um Prettier in deinen Projekten effizient einsetzen zu können.
Wenn nicht, dann schreib mir gerne auf Twitter @Diverent2.
Ich bin gerne für Lob aber auch für Kritik und Anregungen offen, solange sie sachlich und/oder gut argumentiert sind.😊

Und nun viel Erfolg bei der Verwendung von 🎀Prettier!
🙏🏼🙏🏼🙏🏼