🗂 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.
--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, <--
];
--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) => {}
--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!
🙏🏼🙏🏼🙏🏼