Zum Hauptinhalt springen

Prettier 2.0 „2020“

· 36 Min. Lesezeit
Inoffizielle Beta-Übersetzung

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

Bessere Standardeinstellungen, eine bessere CLI und bessere Heuristiken. Ach ja, und TypeScript 3.8.

Nach langer und sorgfältiger Überlegung haben wir uns entschieden, die Standardwerte für die Optionen trailingComma, arrowParens und endOfLine zu ändern. Wir haben die CLI intuitiver gestaltet. Und wir haben endlich die Unterstützung für Node-Versionen älter als 10 eingestellt, was zu einem großen Wartungsaufwand und einem Hindernis für Mitwirkende geworden war. Lesen Sie unten die Details.

Höhepunkte

JavaScript

Verbesserte Heuristik für den Zeilenumbruch bei Methodenverkettungen (#6685 von @mmkal)

Bisher wurde jede Methodenaufrufkette der Länge drei oder mehr automatisch in mehrere Zeilen umgebrochen. Die neue Heuristik basiert auf der Komplexität der Aufrufargumente in der Kette und nicht einfach auf deren Länge. Wenn verkettete Methodenaufrufe Argumente enthalten, die nicht auf den ersten Blick verständlich sind (z.B. Funktionen oder tief verschachtelte Objekte), wird die Kette umgebrochen. Andernfalls dürfen sie in einer Zeile bleiben. Siehe die früheren Issues #3197, #4765, #1565 und #4125 für Kontext und Beispiele.

Um optimale Ergebnisse zu erzielen, stellen Sie sicher, dass Ihr Wert für die printWidth-Option nicht zu hoch ist.

// Prettier 1.19
if (
foo
.one()
.two()
.three() ===
bar
.four()
.five()
.six()
) {
// ...
}

// Prettier 2.0
if (foo.one().two().three() === bar.four().five().six()) {
// ...
}

Endgültige Korrektur für Closure-Style-Typecasts (#7791 von @thorn0, #7011 von @evilebottnawi)

Prettier versucht seit v1.6.0 erfolglos, diese JSDoc-Typassertionen nicht zu beschädigen. Da JSDoc-basierte Typüberprüfung immer häufiger wird, erhielten wir neue Fehlermeldungen zu dieser Syntax. Die Fehler waren knifflig, weil die erforderlichen Klammern um den Ausdruck nicht Teil des AST waren, weshalb Prettier keine gute Möglichkeit hatte, deren Vorhandensein zu erkennen.

Schließlich nutzten wir die createParenthesizedExpressions-Option des Babel-Parsers, um Klammern im AST mit nicht standardkonformen Knoten darzustellen. Dies behebt alle gemeldeten Fehler.

Folglich erkennt Prettier JSDoc-Typecasts nicht, wenn der flow- oder typescript-Parser verwendet wird, was jedoch sinnvoll ist, da diese Syntax in Flow- und TypeScript-Dateien wenig Sinn ergibt.

// Input
const nestedAssertions = /** @type {MyType} */
(/** @type {unknown} */
(x));

// Prettier 1.19
const nestedAssertions /** @type {MyType} */ /** @type {unknown} */ = x;

// Prettier 2.0
const nestedAssertions = /** @type {MyType} */ (/** @type {unknown} */ (x));

Referenzdokumentation für diese Syntax: Closure Compiler, TypeScript (mit --checkJs).

TypeScript

TypeScript 3.8 (#7631 von @thorn0, #7764 von @sosukesuzuki, #7804 von @sosukesuzuki)

Prettier unterstützt nun die neue in TypeScript 3.8 hinzugefügte Syntax:

CLI

Testen, ob übergebene Glob-Muster existierende Dateien sind, bevor sie als Glob behandelt werden (#7587 von @fisker)

Da Dateinamen unter Linux fast beliebige Zeichen enthalten können, sind Zeichenketten wie foo*.js und [bar].css gültige Dateinamen. Bisher musste für die Formatierung einer Datei namens [bar].css eine Glob-Escape-Syntax verwendet werden: prettier "\[bar].css" (funktioniert nicht unter Windows, wo Backslashes als Pfadtrenner behandelt werden) oder prettier "[[]bar].css". Dadurch waren wichtige Anwendungsfälle beeinträchtigt. Beispielsweise übergibt lint-staged absolute Pfade und kennt die Escape-Syntax nicht. Jetzt überprüft die Prettier-CLI zunächst, ob ein Glob als wörtlicher Dateiname aufgelöst werden kann.

Verzeichnisse erweitern, inklusive . (#7660 von @thorn0)

Es ist nun möglich, prettier --write . auszuführen, um alle unterstützten Dateien im aktuellen Verzeichnis und seinen Unterverzeichnissen zu formatieren. Verzeichnisnamen können mit Dateinamen und Glob-Mustern gemischt werden (z.B. prettier src "test/*.spec.js" foo.js).

Außerdem hat sich die Reihenfolge der Dateiverarbeitung geändert. Zuvor wurden alle Dateien alphabetisch sortiert, bevor sie formatiert wurden. Jetzt entspricht ihre Reihenfolge der Reihenfolge der angegebenen Pfade. Für jeden Pfad wird die Liste der aufgelösten Dateien sortiert, aber die vollständige Sortierung der kombinierten Liste entfällt.

Es gibt auch Änderungen bei der Fehlermeldung, wenn übergebene Muster keine Dateien finden. Bisher gab die Prettier-CLI einen "No matching files"-Fehler aus, wenn überhaupt keine Dateien gefunden wurden – für alle Muster zusammen, nicht für ein einzelnes Muster. In Prettier 2.0 gibt die CLI solche Fehler nun auch für einzelne Muster aus.

Breaking Changes

API

Korrektur des Pattern-Matchings für Konfigurations-Overrides, um Punktdateien einzubeziehen (#5813 von @chrisblossom)

Bisher wurden Konfigurations-Overrides nicht auf Dateien angewendet, deren Name mit einem Punkt beginnt.

Ende des Supports für Node-Versionen älter als 10 (#6908 von @fisker)

Die minimal erforderliche Node-Version ist nun 10.13.0. Für unsere Mitwirkenden bedeutet dies, dass keine Umwege mehr nötig sind, um Tests unter Node 4 zum Laufen zu bringen.

Änderung des Standardwerts für trailingComma zu es5 (#6963 von @fisker)

Vor Version 2.0 vermied Prettier standardmäßig nachgestellte Kommas, wo immer möglich. Dies machte den resultierenden JavaScript-Code kompatibel mit inzwischen sehr alten Umgebungen wie IE8, bedeutete aber einige verpasste Gelegenheiten.

Prettier bietet seit seinen Anfängen eine Option zur Konfiguration nachgestellter Kommas, und eine Initiative zur Änderung des Standardwerts existiert seit über drei Jahren. Mit Prettier v2.0 wird der Standardwert nun es5 statt none.

Falls das alte Verhalten weiterhin bevorzugt wird, konfigurieren Sie Prettier bitte mit { "trailingComma": "none" }. Es besteht die Möglichkeit, dass der Standardwert in einer zukünftigen Hauptversion von Prettier zu all geändert wird (was noch mehr nachgestellte Kommas bedeutet), sobald das JavaScript-Ökosystem weiter reift.

Plugin-API: Änderungen in prettier.util (#6993 von @fisker)

  • prettier.util.mapDoc wurde entfernt.
    Verwenden Sie stattdessen prettier.doc.utils.mapDoc.

  • prettier.util.isNextLineEmpty wurde aktualisiert.
    Verwenden Sie isNextLineEmpty(text, node, locEnd) statt isNextLineEmpty(text, node, options).

  • prettier.util.isPreviousLineEmpty wurde aktualisiert.
    Verwenden Sie isPreviousLineEmpty(text, node, locStart) statt isPreviousLineEmpty(text, node, options).

  • prettier.util.getNextNonSpaceNonCommentCharacterIndex wurde aktualisiert.
    Verwenden Sie getNextNonSpaceNonCommentCharacterIndex(text, node, locEnd) statt getNextNonSpaceNonCommentCharacterIndex(text, node, options).

Änderung des Standardwerts für arrowParens zu always (#7430 von @kachkaev)

Seit Version 1.9 gab es in Prettier eine Option, Argumente von Pfeilfunktionen immer in Klammern zu setzen. In Version 2.0 ist dieses Verhalten zum Standard geworden.

// Input
const fn = (x) => y => x + y;

// Prettier 1.19
const fn = x => y => x + y;

// Prettier 2.0
const fn = (x) => (y) => x + y;

Auf den ersten Blick mag das Weglassen von Klammern im isolierten Beispiel oben als bessere Wahl erscheinen, da es weniger visuelles Durcheinander verursacht. Wenn Prettier jedoch Klammern entfernt, wird es jedoch schwieriger, Typannotationen, zusätzliche Argumente, Standardwerte oder eine Vielzahl anderer Dinge hinzuzufügen. Die konsistente Verwendung von Klammern bietet eine bessere Entwicklererfahrung beim Bearbeiten echter Codebasen, was die Änderung rechtfertigt.

Wir empfehlen, den neuen Standardwert zu verwenden. Wenn Sie jedoch das alte Verhalten bevorzugen, konfigurieren Sie Prettier bitte mit { "arrowParens": "avoid" }.

Änderung des Standardwerts für endOfLine zu lf (#7435 von @kachkaev)

Frühere Versionen von Prettier formatierten alle Dateien mit dem *nix-typischen Zeilenende (\n, auch bekannt als LF). Dieses Verhalten wurde in #472 geändert, wodurch die Beibehaltung von Windows-Zeilenenden (\r\n, auch bekannt als CRLF) ermöglicht wurde.

Seit Prettier Version 1.15 ist die Art der Zeilenenden über die Option endOfLine konfigurierbar. Der Standardwert wurde für Abwärtskompatibilität auf auto gesetzt, was bedeutet, dass Prettier die bereits in einer Datei vorhandene Art von Zeilenenden beibehält.

Das bedeutete, dass Prettier gemischte Zeilenenden innerhalb einer Datei in die Art umwandelte, die am Ende der ersten Zeile gefunden wurde. Allerdings konnten Zeilenenden in verschiedenen Dateien weiterhin inkonsistent bleiben. Zudem konnten Mitwirkende auf verschiedenen Betriebssystemen versehentlich Zeilenenden in bereits committeten Dateien ändern, was für Prettier akzeptabel war. Dies führte jedoch zu umfangreichen git diff-Ausgaben und erschwerte die zeilenweise Nachverfolgung der Dateihistorie (git blame).

Wir empfehlen die Verwendung des neuen Standardwerts für endOfLine, der nun lf ist. Es ist ratsam, die Optionsdokumentation zu prüfen, um sicherzustellen, dass Ihr Projekt-Repository korrekt konfiguriert ist. Dies hilft, eine Mischung von Zeilenenden im Repository und eine beeinträchtigte git blame-Funktionalität zu vermeiden. Falls das alte Verhalten bevorzugt wird, konfigurieren Sie Prettier bitte mit { "endOfLine": "auto" }.

Bei Verwendung von Travis CI beachten Sie die autocrlf-Option in .travis.yml.

Zwischenspeichern von Plugin-Suchergebnissen (#7485 von @fisker)

Bisher durchsuchte Prettier das Dateisystem bei jedem prettier.format-Aufruf nach Plugins. Jetzt werden die Suchergebnisse zwischengespeichert. Der Cache kann durch Aufruf von prettier.clearConfigCache() geleert werden.

Entfernung veralteter Optionen und Optionswerte (#6993, #7511, #7533, #7535, #7536 von @fisker)

  • Optionen:

    • useFlowParser (--flow-parser in der CLI) ist seit v0.0.10 veraltet.
  • Optionswerte:

    • parser: babylon (umbenannt in babel in v1.16.0), postcss (umbenannt in css in v1.7.1), typescript-eslint (veralteter Alias für typescript)
    • proseWrap: true (umbenannt in always in v1.9.0), false (umbenannt in never in v1.9.0)
    • trailingComma: true (umbenannt in es5 in v0.19.0), false (umbenannt in none in v0.19.0)

Entfernung des version-Parameters von prettier.getSupportInfo (#7620 von @thorn0)

Seit Prettier 1.8.0 war es möglich, eine Versionsnummer an prettier.getSupportInfo zu übergeben, um Informationen zu unterstützten Sprachen, Optionen etc. früherer Versionen zu erhalten. Diese interessante, aber offenbar wenig nützliche API verursachte ständig Wartungsprobleme und wurde in Prettier 2.0.0 entfernt.

Weitere Änderungen

JavaScript

Stets ein Leerzeichen nach dem function-Schlüsselwort einfügen (#3903 von @j-f1, @josephfrazier, @sosukesuzuki, @thorn0; #7516 von @bakkot)

Bisher wurde ein Leerzeichen nach dem function-Schlüsselwort nur in Funktionsdeklarationen, nicht aber in Funktionsausdrücken eingefügt. Jetzt wird aus Konsistenzgründen stets ein Leerzeichen nach function eingefügt. Die einzige Ausnahme bilden Generator-Deklarationen, bei denen function* als ein zusammenhängendes Wort behandelt wird.

// Prettier 1.19
const identity = function(value) {
return value;
};
function identity(value) {
return value;
}
const f = function<T>(value: T) {};
const g = function*() {};

// Prettier 2.0
const identity = function (value) {
return value;
};
function identity(value) {
return value;
}
const f = function <T>(value: T) {};
const g = function* () {};

Korrigiert instabile Formatierung von benannten Anweisungen mit Kommentaren (#6984 von @clement26695)

// Input
loop1:
//test
const i = 3;

// Prettier 1.19 (first output)
loop1: //test
const i = 3;

// Prettier 1.19 (second output)
//test
loop1: const i = 3;

// Prettier 2.0 (first and second outputs)
//test
loop1: const i = 3;

Korrigiert Formatierung von logischen, binären und Sequenzausdrücken in Template-Literalen (#7010 von @evilebottnawi)

// Input
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${foo || bar}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${foo | bar}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${(foo, bar)}`;

// Prettier 1.19
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${foo ||
bar}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${foo |
bar}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${(foo,
bar)}`;

// Prettier 2.0
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${
foo || bar
}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${
foo | bar
}`;
`111111111 222222222 333333333 444444444 555555555 666666666 777777777 ${
(foo, bar)
}`;

Korrigiert instabile Formatierung von logischen Ausdrücken (#7026 von @thorn0)

// Input
const averredBathersBoxroomBuggyNurl =
bifornCringerMoshedPerplexSawder === 1 ||
(askTrovenaBeenaDependsRowans === 2 || glimseGlyphsHazardNoopsTieTie === 3);

// Prettier 1.19 (first output)
const averredBathersBoxroomBuggyNurl =
bifornCringerMoshedPerplexSawder === 1 ||
askTrovenaBeenaDependsRowans === 2 || glimseGlyphsHazardNoopsTieTie === 3;

// Prettier 1.19 (second output)
const averredBathersBoxroomBuggyNurl =
bifornCringerMoshedPerplexSawder === 1 ||
askTrovenaBeenaDependsRowans === 2 ||
glimseGlyphsHazardNoopsTieTie === 3;

// Prettier 2.0 (first and second outputs)
const averredBathersBoxroomBuggyNurl =
bifornCringerMoshedPerplexSawder === 1 ||
askTrovenaBeenaDependsRowans === 2 ||
glimseGlyphsHazardNoopsTieTie === 3;

Formatiert throw wie return (#7070 von @sosukesuzuki)

// Input
function foo() {
throw this.hasPlugin("dynamicImports") && this.lookahead().type === tt.parenLeft.right;
}

// Prettier 1.19
function foo() {
throw this.hasPlugin("dynamicImports") &&
this.lookahead().type === tt.parenLeft.right;
}


// Prettier 2.0
function foo() {
throw (
this.hasPlugin("dynamicImports") &&
this.lookahead().type === tt.parenLeft.right
);
}

Korrigiert Einrückung in ternären Ausdrücken, die in Bedingungen anderer ternärer Ausdrücke verschachtelt sind (#7087 von @thorn0)

// Input
const foo = (number % 10 >= 2 && (number % 100 < 10 || number % 100 >= 20) ?
kochabCooieGameOnOboleUnweave : annularCooeedSplicesWalksWayWay)
? anodyneCondosMalateOverateRetinol : averredBathersBoxroomBuggyNurl;

// Prettier 1.19
const foo = (number % 10 >= 2 && (number % 100 < 10 || number % 100 >= 20)
? kochabCooieGameOnOboleUnweave
: annularCooeedSplicesWalksWayWay)
? anodyneCondosMalateOverateRetinol
: averredBathersBoxroomBuggyNurl;

// Prettier 2.0
const foo = (
number % 10 >= 2 && (number % 100 < 10 || number % 100 >= 20)
? kochabCooieGameOnOboleUnweave
: annularCooeedSplicesWalksWayWay
)
? anodyneCondosMalateOverateRetinol
: averredBathersBoxroomBuggyNurl;

Passt die Funktionskompositionslogik für Decorators an (#7138 von @brainkim)

Da Decorators die folgende Zeile modifizieren, kann das Aufteilen von Decorator-Argumenten auf mehrere Zeilen die Beziehung zwischen Decorator und Zielobjekt verschleiern, was zu weniger lesbarem Code führt. Daher wurde die in #6033 eingeführte Funktionskompositionslogik geändert, um Decorator-Aufrufe auszuschließen.

// Input
export class Item {
@OneToOne(() => Thing, x => x.item)
thing!: Thing;
}

// Prettier 1.19
export class Item {
@OneToOne(
() => Thing,
x => x.item,
)
thing!: Thing;
}

// Prettier 2.0
export class Item {
@OneToOne(() => Thing, x => x.item)
thing!: Thing;
}

Korrigiert die Semikolon-Platzierung in leeren return-Anweisungen mit Kommentar (#7140 von @sosukesuzuki)

// Input
return // comment
;

// Prettier 1.19
return // comment;

// Prettier 2.0
return; // comment

Beachtet die Bedeutung von Leerzeichen in HTML-Template-Literalen (#7208 von @saschanaz)

Prettier fügte bisher bei jedem HTML-Template-String Zeilenumbrüche ein, was zu unerwarteten Leerzeichen im gerenderten HTML führen konnte. Dies geschieht nun nicht mehr, es sei denn, die Option --html-whitespace-sensitivity ignore wird angegeben.

// Input
html`<div>`;
html` <span>TEXT</span> `;

// Prettier 1.19
html`
<div></div>
`;
html`
<span>TEXT</span>
`;

// Prettier 2.0
html`<div></div>`;
html` <span>TEXT</span> `;

Entfernt unnötige Klammern bei Verwendung von yield mit JSX (#7367 von @cola119)

// Input
function* f() {
yield <div>generator</div>;
}

// Prettier 1.19
function* f() {
yield (<div>generator</div>);
}

// Prettier 2.0
function* f() {
yield <div>generator</div>;
}

Behält Klammern um Komma-Ausdrücke in Default-Export-Deklarationen (#7491 von @fisker)

Das Weglassen dieser Klammern macht den Code ungültig.

// Input
export default (1, 2);

// Prettier 1.19
export default 1, 2;

// Prettier 2.0
export default (1, 2);

Behebung von Randfällen mit Klammern bei optionalem Chaining (#7500 von @thorn0)

// Input
(foo?.bar)();
new (foo?.bar)();

// Prettier 1.19
foo?.bar();
new foo?.bar();

// Prettier 2.0
(foo?.bar)();
new (foo?.bar)();

undefined in bedingten Ausdrücken innerhalb von JSX nicht mehr in Klammern setzen (#7504 von @fisker)

Bislang wurden Klammern um alle Ausdrücke außer null hinzugefügt. Jetzt wird auch undefined ausgenommen.

// Input
foo ? <span>loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx</span> :
undefined
foo ? <span>loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx</span> :
null

// Prettier 1.19
foo ? (
<span>
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx
</span>
) : (
undefined
);
foo ? (
<span>
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx
</span>
) : null;

// Prettier 2.0
foo ? (
<span>
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx
</span>
) : undefined;
foo ? (
<span>
loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong jsx
</span>
) : null;

Beibehaltung der Kommentarposition bei Zuweisungen/Variablen (#7709 von @sosukesuzuki)

// Input
const foo = /* comments */
bar;

// Prettier 1.19
const foo /* comments */ = bar;

// Prettier 2.0
const foo = /* comments */ bar;

TypeScript

Babel als alternativer Parser für TypeScript (#6400 von @JounQin & @thorn0)

Ein neuer Wert für die parser-Option wurde hinzugefügt: babel-ts, der Babels TypeScript-Plugin nutzt. Der babel-ts-Parser unterstützt JavaScript-Funktionen, die TypeScript noch nicht unterstützt (ECMAScript-Vorschläge, z.B. private Methoden und Accessoren), ist jedoch weniger tolerant bei der Fehlerbehebung und weniger erprobt als der typescript-Parser. Obwohl Babels TypeScript-Plugin recht ausgereift ist, sind die erzeugten ASTs nicht zu 100% kompatibel. Wir haben versucht, die Abweichungen zu berücksichtigen, aber es gibt wahrscheinlich noch Fälle, in denen Code unterschiedlich oder sogar fehlerhaft formatiert wird. Wir rufen unsere Nutzer auf, uns bei der Identifizierung solcher Fälle zu unterstützen. Sollten Ihnen welche auffallen, melden Sie sie bitte. Langfristig wird dies zur Vereinheitlichung des AST-Formats in zukünftigen Parser-Versionen beitragen und so zu einem besseren JavaScript-Parser-Ökosystem führen.

Korrektur der Formatierung komplexer Typen in Return-Type-Annotationen von Pfeilfunktionen (#6901 von @sosukesuzuki)

// Input
export const getVehicleDescriptor = async (
vehicleId: string
): Promise<
Collections.Parts.PrintedCircuitBoardAssembly["attributes"] & undefined
> => {};

// Prettier 1.19
export const getVehicleDescriptor = async (
vehicleId: string
): Promise<Collections.Parts.PrintedCircuitBoardAssembly["attributes"] &
undefined> => {};

// Prettier 2.0
export const getVehicleDescriptor = async (
vehicleId: string
): Promise<
Collections.Parts.PrintedCircuitBoardAssembly["attributes"] & undefined
> => {};

JSDoc-exklusive Typen unverändert ausgeben statt Fehler zu werfen (#7020 von @thorn0)

Eine weitere Korrektur bezüglich Fehlerbehebung. Besonders nützlich für die Migration von Flow zu TypeScript.

// Input
function fromFlow(arg: ?Maybe) {}

// Prettier 1.19
Error: unknown type: "TSJSDocNullableType"

// Prettier 2.0
function fromFlow(arg: ?Maybe) {}

Keine nachgestellten Kommas nach Rest-Elementen in Tupeln ausgeben (#7075 von @thorn0)

  • Ein Rest-Element ist stets das letzte Element eines Tupeltyps. Danach kann nichts mehr folgen.

  • Während TypeScript dieses Komma akzeptiert, kann Babel es nicht parsen

  • Bei Funktionsparametern und Array-Destrukturierung wäre ein solches Komma ein Syntaxfehler. Dessen Beibehaltung in Tupeln wäre inkonsistent.

// Input
type ValidateArgs = [
{
[key: string]: any;
},
string,
...string[],
];

// Prettier 1.19
type ValidateArgs = [
{
[key: string]: any;
},
string,
...string[],
];

// Prettier 2.0
type ValidateArgs = [
{
[key: string]: any;
},
string,
...string[]
];

Korrektur der Einrückung von Pfeilfunktionen in Variablendeklarationen mit nachfolgenden Kommentaren (#7094 von @sosukesuzuki)

Dies konnte bei Code im Semikolon-freien Stil auftreten, wenn die Anweisung nach der Variablendeklaration mit einem Semikolon versehen war, um ASI-Probleme zu vermeiden.

// Input
const foo = () => {
return
}

// foo
;[1,2,3].forEach(bar)

// Prettier 1.19
const foo = () => {
return;
};

// foo
[1, 2, 3].forEach(bar);

// Prettier 2.0
const foo = () => {
return;
};

// foo
[1, 2, 3].forEach(bar);

Korrektur der Kommentarausgabe in Funktionstypen (#7104 von @thorn0)

// Input
type f1 = (
currentRequest: {a: number},
// TODO this is a very very very very long comment that makes it go > 80 columns
) => number;

// Prettier 1.19
type f1 = (currentRequest: {
a: number;
}) => // TODO this is a very very very very long comment that makes it go > 80 columns
number;

// Prettier 2.0
type f1 = (
currentRequest: { a: number }
// TODO this is a very very very very long comment that makes it go > 80 columns
) => number;

Korrektur der Formatierung von Kommentaren für funktionsähnliche Knoten (#7144 von @armano2)

// Input
interface foo1 {
bar1/* foo */ (/* baz */) // bat
bar2/* foo */ ? /* bar */ (/* baz */) /* bat */;
bar3/* foo */ (/* baz */) /* bat */
bar4/* foo */ ? /* bar */ (bar: /* baz */ string): /* bat */ string;
/* foo */ (/* bar */): /* baz */ string;
/* foo */ (bar: /* bar */ string): /* baz */ string;
/* foo */ new /* bar */ (a: /* baz */ string): /* bat */ string
/* foo */ new /* bar */ (/* baz */): /* bat */ string
}

type foo7 = /* foo */ (/* bar */) /* baz */ => void
type foo8 = /* foo */ (a: /* bar */ string) /* baz */ => void
let foo9: new /* foo */ (/* bar */) /* baz */ => string;
let foo10: new /* foo */ (a: /* bar */ string) /* baz */ => string;

// Prettier 1.19
interface foo1 {
bar1 /* foo */ /* baz */(); // bat
bar2 /* foo */ /* bar */ /* baz */ /* bat */?();
bar3 /* foo */ /* baz */() /* bat */;
bar4 /* foo */?(/* bar */ bar: /* baz */ string): /* bat */ string;
/* foo */ (): /* bar */ /* baz */ string;
/* foo */ (bar: /* bar */ string): /* baz */ string;
/* foo */ new (/* bar */ a: /* baz */ string): /* bat */ string;
/* foo */ new (): /* bar */ /* baz */ /* bat */ string;
}

type foo7 = /* foo */ () => /* bar */ /* baz */ void;
type foo8 = /* foo */ (a: /* bar */ string) => /* baz */ void;
let foo9: new () => /* foo */ /* bar */ /* baz */ string;
let foo10: new (/* foo */ a: /* bar */ string) => /* baz */ string;

// Prettier 2.0
interface foo1 {
bar1 /* foo */(/* baz */); // bat
bar2 /* foo */ /* bar */?(/* baz */) /* bat */;
bar3 /* foo */(/* baz */) /* bat */;
bar4 /* foo */?(/* bar */ bar: /* baz */ string): /* bat */ string;
/* foo */ (/* bar */): /* baz */ string;
/* foo */ (bar: /* bar */ string): /* baz */ string;
/* foo */ new (/* bar */ a: /* baz */ string): /* bat */ string;
/* foo */ new (/* baz */): /* bar */ /* bat */ string;
}

type foo7 = /* foo */ (/* bar */) => /* baz */ void;
type foo8 = /* foo */ (a: /* bar */ string) => /* baz */ void;
let foo9: new (/* bar */) => /* foo */ /* baz */ string;
let foo10: new (/* foo */ a: /* bar */ string) => /* baz */ string;
// Input
abstract class Test {
abstract foo12 /* foo */ (a: /* bar */ string): /* baz */ void
abstract foo13 /* foo */ (/* bar */) /* baz */
}

// Prettier 1.19
Error: Comment "foo" was not printed. Please report this error!

// Prettier 2.0
abstract class Test {
abstract foo12 /* foo */(a: /* bar */ string): /* baz */ void;
abstract foo13 /* foo */(/* bar */); /* baz */
}

Korrektur der Ausgabe von Mapped Types ohne Template-Typ (#7221 von @cola119)

// Input
type A = { [key in B] };

// Prettier 1.19
type A = { [key in B]: };

// Prettier 2.0
type A = { [key in B] };

Behebung von Randfällen bei der Formatierung von Index-Signaturen (#7228 von @cola119)

Obwohl Index-Signaturen ohne Typannotationen oder mit mehreren Parametern in TypeScript ungültig sind, unterstützt der TypeScript-Parser diese Syntax. Im Rahmen der bisherigen Fehlerbehebungsbemühungen stellt Prettier nun sicher, dass die Ausgabe in diesen Fällen weiterhin geparst werden kann. Frühere Versionen erzeugten nicht parsbaren Code.

// Input
type A = { [key: string] };
type B = { [a: string, b: string]: string; };

// Prettier 1.19
type A = { [key: string]: };
type B = { [a: stringb: string]: string };

// Prettier 2.0
type A = { [key: string] };
type B = { [a: string, b: string]: string };

Korrektur der Kommentarformatierung in leeren Typparametern (#7729 von @sosukesuzuki)

// Input
const a: T</* comment */> = 1;

// Prettier 1.19
Error: Comment "comment" was not printed. Please report this error!

// Prettier 2.0
const a: T</* comment */> = 1;

Flow

Unterstützung für symbol hinzugefügt (#7472 von @fisker)

Ein neuer AST-Knotentyp wurde in flow@0.114.0 eingeführt und wird nun erkannt.

// Input
const x: symbol = Symbol();

// Prettier after updating Flow, but without this fix
Error: unknown type: "SymbolTypeAnnotation"

// Prettier 2.0
const x: symbol = Symbol();

Unterstützung für Dekoratoren hinzugefügt (#7482 von @fisker)

// Input
/* @flow */
@decorator4
class Foo {
@decorator1
method1() {}

@decorator2
@decorator3
method2() {}
}

// Prettier 1.19
SyntaxError: Unexpected token `@`, expected the token `class` (2:1)

// Prettier 2.0
/* @flow */
@decorator4
class Foo {
@decorator1
method1() {}

@decorator2
@decorator3
method2() {}
}

Korrektur privater Klassenfeld-Deklarationen (#7484 von @fisker)

// Input
class Foo {
#privateProp: number;
}

// Prettier 1.19
class Foo {
privateProp: number;
}

// Prettier 2.0
class Foo {
#privateProp: number;
}

CSS

Elementnamen in CSS-Selektoren nicht mehr kleinschreiben (#6947 von @ark120202)

Bisher bewahrte Prettier die Schreibweise unbekannter Elementnamen, schrieb aber Namen von HTML-Elementen klein. Dies verursachte Probleme, wenn CSS auf ein case-sensitives Dokument angewendet wurde und ein Element mit demselben Namen wie in HTML existierte (z.B. in NativeScript). Prettier erhält nun stets die ursprüngliche Schreibweise.

/* Input */
Label {
}

/* Prettier 1.19 */
label {
}

/* Prettier 2.0 */
Label {
}

SCSS

Kein zusätzliches Komma nach dem letzten Kommentar in Maps (#6918 von @fisker)

Bisher wurde bei trailingComma = es5 ein zusätzliches Komma nach dem letzten Kommentar in einer SCSS-Map eingefügt.

// Input
$my-map: (
'foo': 1, // Comment
'bar': 2, // Comment
);

// Prettier 1.19
$my-map: (
"foo": 1,
// Comment
"bar": 2,
// Comment,
);

// Prettier 2.0
$my-map: (
"foo": 1,
// Comment
"bar": 2,
// Comment
);

Korrektur des Leerraums bei SCSS-Verkettungen (#7211 von @sasurau4)

// Input
a {
background-image: url($test-path + 'static/test.jpg');
}

// Prettier 1.19
a {
background-image: url($test-path+"static/test.jpg");
}

// Prettier 2.0
a {
background-image: url($test-path + "static/test.jpg");
}

Less

Behebung langjähriger Probleme durch Update von postcss-less (#6981 von @fisker, #7021 von @evilebottnawi, @thorn0)

  • each wird nun unterstützt (#5653).

  • !important wurde fälschlicherweise aus Mixin-Aufrufparametern verschoben (#3544).

  • Kommentare in Rulesets innerhalb von Mixin-Aufrufen verursachten doppelte Semikolons (#3096).

  • ::before wurde in Mixin-Aufrufparametern fehlerhaft umgebrochen (#5791).

HTML

Kommentare in pre-Tags verursachten falsche Formatierung des folgenden schließenden Tags (#5959 von @selvazhagan)

<!-- Input -->
<details>
<pre>
<!-- TEST -->
</pre></details>

<!-- Prettier 1.19 -->
<details>
<pre>
<!-- TEST -->
</pre></details</details
>

<!-- Prettier 2.0 -->
<details>
<pre>
<!-- TEST -->
</pre>
</details>

Doppelpunkt nicht mehr als Namespace-Präfix-Trennzeichen in Tagnamen behandeln (#7273 von @fisker)

In HTML5 haben Doppelpunkte in Tagnamen keine besondere Bedeutung. Prettier behandelte sie zuvor nach XML-Art als Namespace-Präfix-Trenner, was nun geändert wurde. Praktisch bedeutet dies: Tags mit Doppelpunkten im Namen werden nun wie normale HTML-Tags behandelt. Bei bekannten Standard-Tags kann der Name kleingeschrieben werden, bei benutzerdefinierten Elementen bleibt die Groß-/Kleinschreibung erhalten. Wenn --html-whitespace-sensitivity auf css gesetzt ist, werden unbekannte Elemente als inline behandelt.

<!-- Input -->
<with:colon>
<div> looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog block </div>
<DIV> block </DIV><DIV> block </DIV> <DIV> block </DIV><div> block </div><div> block </div>
<pre> pre pr
e</pre>
<textarea> pre-wrap pr
e-wrap </textarea>
<span> looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog inline </span>
<span> inline </span><span> inline </span> <span> inline </span><span> inline </span>
</with:colon>

<!-- Prettier 1.19 -->
<with:colon>
<div>
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog block
</div>
<DIV> block </DIV><DIV> block </DIV> <DIV> block </DIV><div> block </div
><div> block </div>
<pre> pre pr e</pre>
<textarea> pre-wrap pr e-wrap </textarea>
<span>
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog inline
</span>
<span> inline </span><span> inline </span> <span> inline </span
><span> inline </span>
</with:colon>

<!-- Prettier 2.0 -->
<with:colon>
<div>
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog block
</div>
<div>block</div>
<div>block</div>
<div>block</div>
<div>block</div>
<div>block</div>
<pre>
pre pr
e</pre
>
<textarea>
pre-wrap pr
e-wrap </textarea
>
<span>
looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog inline
</span>
<span> inline </span><span> inline </span> <span> inline </span
><span> inline </span>
</with:colon>

Kein Absturz mehr bei fehlerhaftem HTML (#7293 von @fisker)

<!-- Input -->
<div><span>
<

<!-- Prettier 1.19 -->
TypeError: Cannot read property 'start' of null

<!-- Prettier 2.0 -->
<div><span> < </span></div>

Korrektur von Parse-Fehlern in srcset-Attributen (#7295 von @fisker)

<!-- Input -->
<img

srcset="
/media/examples/surfer-240-200.jpg
">

<!-- Prettier 1.19 -->
Error: Mixed descriptor in srcset is not supported

<!-- Prettier 2.0 -->
<img srcset="/media/examples/surfer-240-200.jpg" />

Fehlerbehebung bei nicht geschlossenen Tags innerhalb von pre-Tags (#7392 von @fisker)

<!-- Input -->
<pre><br /></pre>
<pre><hr></pre>

<!-- Prettier 1.19 -->
TypeError: Cannot read property 'start' of null

<!-- Prettier 2.0 -->
<pre><br /></pre>
<pre><hr /></pre>

Konsistente Formatierung von selbstschließenden Tags (#7395 von @fisker)

<!-- Input -->
<span><input type="checkbox"/> </span>
<span><span><input type="checkbox"/></span></span>
<span><input type="checkbox"/></span>

<!-- Prettier 1.19 -->
<span><input type="checkbox" /> </span>
<span
><span><input type="checkbox"/></span
></span>
<span><input type="checkbox"/></span>

<!-- Prettier 2.0 -->
<span><input type="checkbox" /> </span>
<span
><span><input type="checkbox" /></span
></span>
<span><input type="checkbox" /></span>

Unerwartete Leerzeilen nach table-Tags entfernt (#7461 von @ikatyang)

<!-- Input -->
<table><tr>
</tr>
</table><div>Should not insert empty line before this div</div>

<!-- Prettier 1.19 -->
<table>
<tr></tr>
</table>

<div>Should not insert empty line before this div</div>

<!-- Prettier 2.0 -->
<table>
<tr></tr>
</table>
<div>Should not insert empty line before this div</div>

Formatierung des Werts von HTML-class-Attributen (#7555 von @fisker)

<!-- Input -->
<div class=" foo
bar baz"></div>
<div class="
another element with so many classes
even can not fit one line
really a lot and lot of classes
"></div>

<!-- Prettier 1.19 -->
<div
class=" foo
bar baz"
></div>
<div
class="
another element with so many classes
even can not fit one line
really a lot and lot of classes
"
></div>

<!-- Prettier 2.0 -->
<div class="foo bar baz"></div>
<div
class="another element with so many classes even can not fit one line really a lot and lot of classes"
></div>

Formatierung des Werts von HTML-style-Attributen (#7556 von @fisker)

<!-- Input -->
<div style=" color : red;
display :inline ">
</div>
<div style=" color : red;
display :inline; height: auto;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0; ">
</div>

<!-- Prettier 1.19 -->
<div
style=" color : red;
display :inline "
></div>
<div
style=" color : red;
display :inline; height: auto;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0; "
></div>


<!-- Prettier 2.0 -->
<div style="color: red; display: inline;"></div>
<div
style="
color: red;
display: inline;
height: auto;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
"
></div>

Unterstützung von <!-- prettier ignore --> für Textinhalte (#7654 von @graemeworthy)

Zuvor funktionierte dies nur für Tags. Nützlich zum Schutz von Makros und Präprozessor-Befehlen vor Formatierungsänderungen.

<!-- Input -->
<!-- prettier-ignore -->
A super long string that has been marked as ignore because it was probably generated by some script.

<!-- Prettier 1.19 -->
<!-- prettier-ignore -->
A super long string that has been marked as ignore because it was probably
generated by some script.

<!-- Prettier 2.0 -->
<!-- prettier-ignore -->
A super long string that has been marked as ignore because it was probably generated by some script.
<!-- Input -->
<!-- prettier-ignore -->
| Dogs | Cats | Weasels | Bats | Pigs | Mice | Hedgehogs | Capybaras | Rats | Tigers |
| ---- | ---- | ------- | ---- | ---- | ---- | --------- | --------- | ---- | ------ |
| 1 | 1 | 0 | 0 | 1 | 1 | 5 | 16 | 4 | 0 |

<!-- Prettier 1.19 -->
<!-- prettier-ignore -->
| Dogs | Cats | Weasels | Bats | Pigs | Mice | Hedgehogs | Capybaras | Rats |
Tigers | | ---- | ---- | ------- | ---- | ---- | ---- | --------- | --------- |
---- | ------ | | 1 | 1 | 0 | 0 | 1 | 1 | 5 | 16 | 4 | 0 |

<!-- Prettier 2.0 -->
<!-- prettier-ignore -->
| Dogs | Cats | Weasels | Bats | Pigs | Mice | Hedgehogs | Capybaras | Rats | Tigers |
| ---- | ---- | ------- | ---- | ---- | ---- | --------- | --------- | ---- | ------ |
| 1 | 1 | 0 | 0 | 1 | 1 | 5 | 16 | 4 | 0 |

Vue

Formatierung von Vue-SFCs mit JSX-Script-Tags (#7180 von @sosukesuzuki)

<!-- Input -->
<script lang="jsx">
export default {
data: () => ({
message: 'hello with jsx'
}),
render(h) {



return <div>{this.message}</div>
}
}
</script>

<!-- Prettier 1.19 -->
<script lang="jsx">
export default {
data: () => ({
message: 'hello with jsx'
}),
render(h) {



return <div>{this.message}</div>
}
}
</script>

<!-- Prettier 2.0 -->
<script lang="jsx">
export default {
data: () => ({
message: "hello with jsx"
}),
render(h) {
return <div>{this.message}</div>;
}
};
</script>

Einfache String-Literale in Attributen nicht mehr in neue Zeile umbrechen (#7479 von @fisker)

<!-- Input -->
<template>
<MyComponent
:attr1="`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong ${template} literal value`"
:attr2="'loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string literal value'"/>
</template>

<!-- Prettier 1.19 -->
<template>
<MyComponent
:attr1="
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong ${template} literal value`
"
:attr2="
'loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string literal value'
"
/>
</template>

<!-- Prettier 2.0 -->
<template>
<MyComponent
:attr1="`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong ${template} literal value`"
:attr2="'loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong string literal value'"
/>
</template>

Korrektur der Einrückung von Vue-Ausdrücken (#7781 von @fisker)

<!-- Input -->
<template>
<MyComponent v-if="
long_long_long_long_long_long_long_condition_1 && long_long_long_long_long_long_long_condition_2 &&
long_long_long_long_long_long_long_condition_3 &&
long_long_long_long_long_long_long_condition_4
"
:attr="
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 1` +
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 2`
"
/>
</template>

<!-- Prettier 1.19 -->
<template>
<MyComponent
v-if="
long_long_long_long_long_long_long_condition_1 &&
long_long_long_long_long_long_long_condition_2 &&
long_long_long_long_long_long_long_condition_3 &&
long_long_long_long_long_long_long_condition_4
"
:attr="
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 1` +
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 2`
"
/>
</template>

<!-- Prettier 2.0 -->
<template>
<MyComponent
v-if="
long_long_long_long_long_long_long_condition_1 &&
long_long_long_long_long_long_long_condition_2 &&
long_long_long_long_long_long_long_condition_3 &&
long_long_long_long_long_long_long_condition_4
"
:attr="
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 1` +
`loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooog string 2`
"
/>
</template>

Angular

Inoffizielle rudimentäre Unterstützung für häufig genutzte Direktiven von AngularJS 1.x (#6869 von @thorn0)

Trotz einiger Syntax-Inkompatibilitäten (Einweg-Bindungen und Präzedenz von |) zwischen den Ausdruckssprachen des alten AngularJS und dem neuen Angular sind beide Sprachen kompatibel genug, damit Legacy- und Hybrid-Projekte mit AngularJS-Basis von Prettier profitieren können. Bisher formatierte Prettier AngularJS-Templates mit dem Angular-Parser nur Ausdrücke in Interpolationen. Nun werden auch einige der am häufigsten verwendeten AngularJS-Direktiven formatiert, nämlich: ng-if, ng-show, ng-hide, ng-class, ng-style.

<!-- Input -->
<div ng-if="$ctrl .shouldShowWarning&&!$ctrl.loading ">Warning!</div>

<!-- Prettier 1.19 -->
<div ng-if="$ctrl .shouldShowWarning&&!$ctrl.loading ">Warning!</div>

<!-- Prettier 2.0 -->
<div ng-if="$ctrl.shouldShowWarning && !$ctrl.loading">Warning!</div>

Korrektur der Formatierung von i18n-Attributen (#7371 von @thorn0)

Prettier 1.19 fügte Unterstützung für die Formatierung von i18n-Attributen hinzu, aber das Setzen der schließenden Anführungszeichen in einer neuen Zeile brach jedoch benutzerdefinierte IDs. Dies ist nun behoben.

<!-- Input -->
<div i18n-prop="Special-property|This is a special property with much important information@@MyTextId"
prop="My Text"></div>

<!-- Prettier 1.19 -->
<div
i18n-prop="
Special-property|This is a special property with much important
information@@MyTextId
"
prop="My Text"
></div>

<!-- Prettier 2.0 -->
<div
i18n-prop="
Special-property|This is a special property with much important
information@@MyTextId"
prop="My Text"
></div>

Handlebars (Alpha)

Korrektur überflüssiger Zeilenumbrüche in ConcatStatement (#7051 von @dcyriller)

{{!-- Input --}}
<a href="a-very-long-href-from-a-third-party-marketing-platform{{id}}longer-than-eighty-chars">Link</a>

{{!-- Prettier 1.19 --}}
<a
href="a-very-long-href-from-a-third-party-marketing-platform
{{id}}
longer-than-eighty-chars"
>
Link
</a>

{{!-- Prettier 2.0 --}}
<a
href="a-very-long-href-from-a-third-party-marketing-platform{{id}}longer-than-eighty-chars"
>
Link
</a>

und

{{!-- Input --}}
<div class="hello {{if goodbye true}} {{if goodbye false}} {{if goodbye true}} {{if goodbye false}} {{if goodbye true}}">
Hello
</div>

{{!-- Prettier 1.19 --}}
<div
class="hello
{{if goodbye true}}

{{if goodbye false}}

{{if goodbye true}}

{{if goodbye false}}

{{if goodbye true}}"
>
Hello
</div>

{{!-- Prettier 2.0 --}}
<div
class="hello {{if goodbye true}} {{if goodbye false}} {{if goodbye true}} {{if
goodbye
false
}} {{if goodbye true}}"
>
Hello
</div>

Behebung eines Problems mit fallenden Mustaches (#7052 von @dcyriller)

{{!-- Input --}}
<GlimmerComponent @progress={{aPropertyEndingAfterEightiethColumnToHighlightAWeirdClosingParenIssue}} />

{{!-- Prettier 1.19 --}}
<GlimmerComponent
@progress={{aPropertyEndingAfterEightiethColumnToHighlightAWeirdClosingParenIssue
}}
/>

{{!-- Prettier 2.0 --}}
<GlimmerComponent
@progress={{aPropertyEndingAfterEightiethColumnToHighlightAWeirdClosingParenIssue}}
/>

Verbesserte Ausgabe von MustacheStatement (#7157 von @dcyriller)

{{!-- Input --}}
<p>Hi here is your name, as it will be displayed {{firstName}} {{lastName}} , welcome!</p>

{{!-- Prettier 1.19 --}}
<p>
Hi here is your name, as it will be displayed {{firstName}} {{lastName
}} , welcome!
</p>

{{!-- Prettier 2.0 --}}
<p>
Hi here is your name, as it will be displayed {{firstName}} {{
lastName
}} , welcome!
</p>

Unterstützung für prettier-ignore hinzugefügt (#7275 von @chadian)

{{! Input }}
{{! prettier-ignore }}
<div>
"hello! my parent was ignored"
{{#my-crazy-component "shall" be="preserved"}}
<This

is="preserved"
/>
{{/my-crazy-component}}
</div>

{{#a-normal-component isRestoredTo = "order" }}
<ThisWillBeNormal backTo = "normal" />
{{/a-normal-component}}

{{! Prettier 1.19 }}
{{! prettier-ignore }}
<div>
"hello! my parent was ignored"
{{#my-crazy-component "shall" be="preserved"}}
<This is="preserved" />
{{/my-crazy-component}}
</div>

{{#a-normal-component isRestoredTo="order"}}
<ThisWillBeNormal backTo="normal" />
{{/a-normal-component}}

{{! Prettier 2.0 }}
{{! prettier-ignore }}
<div>
"hello! my parent was ignored"
{{#my-crazy-component "shall" be="preserved"}}
<This

is="preserved"
/>
{{/my-crazy-component}}
</div>

{{#a-normal-component isRestoredTo='order'}}
<ThisWillBeNormal backTo='normal' />
{{/a-normal-component}}

Unterstützung für die Ausgabe von inline Handlebars in HTML (#7306 von @dcyriller)

<!-- Input -->
<script type="text/x-handlebars-template">
{{component arg1='hey' arg2=(helper this.arg7 this.arg4) arg3=anotherone arg6=this.arg8}}
</script>

<!-- Prettier 1.19 -->
<script type="text/x-handlebars-template">
{{component arg1='hey' arg2=(helper this.arg7 this.arg4) arg3=anotherone arg6=this.arg8}}
</script>

<!-- Prettier 2.0 -->
<script type="text/x-handlebars-template">
{{component
arg1='hey'
arg2=(helper this.arg7 this.arg4)
arg3=anotherone
arg6=this.arg8
}}
</script>

Korrektur entfernter Werte aus AttrNode (#7552 von @bantic)

{{!-- Input --}}
<ul class="abc
def">
</ul>

{{!-- Prettier 1.19 --}}
<ul class></ul>

{{!-- Prettier 2.0 --}}
<ul class="abc
def">
</ul>

Beibehaltung von Whitespace-Steuerzeichen (#7575 von @mahirshah)

{{!-- Input --}}
{{~#if bar}}
if1
{{~else~}}
else
{{~/if~}}

{{!-- Prettier 1.19 --}}
{{#if bar}}
if1
{{else}}
else
{{/if}}

{{!-- Prettier 2.0 --}}
{{~#if bar}}
if1
{{~else~}}
else
{{~/if~}}

GraphQL

Verbesserte Erkennung von Trennzeichen zwischen Interfaces (#7305 von @fisker)

Obwohl die Verwendung von Kommas zur Trennung mehrerer implementierter Interfaces eine veraltete Syntax ist, behält Prettier zur Unterstützung von Legacy-Anwendungsfällen das ursprüngliche Trennzeichen bei und ersetzt Kommas nicht willkürlich durch kaufmännische Und-Zeichen. Diese Logik enthielt jedoch zuvor einen Fehler, sodass das falsche Trennzeichen in der Ausgabe landen konnte. Dies ist nun behoben.

# Input
type Type1 implements A, B
# { & <-- Removing this comment changes the separator in 1.19
{a: a}

type Type2 implements A, B & C{a: a}

# Prettier 1.19
type Type1 implements A & B {
# { & <-- Removing this comment changes the separator in 1.19
a: a
}

type Type2 implements A & B & C {
a: a
}

# Prettier 2.0
type Type1 implements A, B {
# { & <-- Removing this comment changes the separator in 1.19
a: a
}

type Type2 implements A, B & C {
a: a
}

Markdown

Korrekte Behandlung von nullbasierten Listen (#6852 von @evilebottnawi)

<!-- Input -->
0. List
1. List
2. List

<!-- Prettier 1.19 -->
0. List
1. List
1. List

<!-- Prettier 2.0 -->
0. List
1. List
2. List

Behebung der HTML-Formatierung, wenn das Start-Tag nach einem Listenelement beginnt (#7181 und #7220 von @sasurau4)

Bisher fügte Prettier bei der Formatierung eines HTML-Tags direkt nach einem Listenelement einen Einzug hinzu und unterbrach dadurch die Beziehung zwischen öffnendem und schließendem Tag. Jetzt ändert Prettier nichts mehr in diesem Fall.

<!-- Input -->
- A list item.
<details><summary>Summary</summary>
<p>

- A list item.

</p>
</details>

- A list item
<blockquote>asdf</blockquote>

<!-- Prettier 1.19 -->
- A list item.

<details><summary>Summary</summary>
<p>

- A list item.

</p>
</details>

- A list item
<blockquote>asdf</blockquote>

<!-- Prettier 2.0 -->
- A list item.
<details><summary>Summary</summary>
<p>

- A list item.

</p>
</details>

- A list item
<blockquote>asdf</blockquote>

Formatierung mehrzeiliger Fußnoten korrigiert (#7203 von @sasurau4)

<!-- Input -->
Here's a statement[^footnote].

[^footnote]:
Here's a multi-line footnote walking back the above statement, and showing
how it's all totally bollocks.

<!-- Prettier 1.19 -->
Here's a statement[^footnote].

[^footnote]:

Here's a multi-line footnote walking back the above statement, and showing
how it's all totally bollocks.

<!-- Prettier 2.0 -->
Here's a statement[^footnote].

[^footnote]:
Here's a multi-line footnote walking back the above statement, and showing
how it's all totally bollocks.

MDX

Unterstützung für JSX-Fragmente hinzugefügt (#6398 von @JounQin)

<!-- Input -->
<>
test <World /> test
</> 123

<!-- Prettier 1.19 -->
<>
test <World /> test
</> 123

<!-- Prettier 2.0 -->
<>
test <World /> test
</> 123

Behebung von JSX-Parsing-Problemen aus Prettier 1.19 (#6949 von @Tigge & @thorn0)

Das MDX-Parsing für JSX schlug fehl, wenn JSX-Elemente auftraten, die nicht als HTML geparst werden konnten, wie z.B. <Tag value={{a: 'b'}}>test</Tag>

<!-- Input -->

<Tag value={ {a : 'b' } }>test</ Tag>

<Foo bg={ 'red' } >
<div style={{ display: 'block'} }>
<Bar >hi </Bar>
{ hello }
{ /* another comment */}
</div>
</Foo>

<!-- Prettier 1.19 -->

SyntaxError: Unexpected closing tag "Tag". It may happen when the tag has already been closed by another tag. For more info see https://www.w3.org/TR/html5/syntax.html#closing-elements-that-have-implied-end-tags (1:35)
> 1 | <Tag value={ {a : 'b' } }>test</ Tag>

<!-- Prettier 2.0 -->

<Tag value={{ a: "b" }}>test</Tag>

<Foo bg={"red"}>
<div style={{ display: "block" }}>
<Bar>hi </Bar>
{hello}
{/* another comment */}
</div>
</Foo>

CLI

Unterstützung für Dateiendungen .cjs und .yaml.sed hinzugefügt (#7210 von @sosukesuzuki)

# Prettier 1.19
$ prettier test.cjs
test.cjs[error] No parser could be inferred for file: test.cjs

# Prettier 2.0
$ prettier test.cjs
"use strict";
console.log("Hello, World!");

Berücksichtigung von --ignore-path bei Ausführung aus einem Unterverzeichnis (#7588 von @heylookltsme)

Der für das Filtern ignorierter Dateien verwendete Dateiname wird jetzt relativ zum --ignore-path Pfad (falls angegeben) statt zum aktuellen Arbeitsverzeichnis bestimmt.

Entfernung von --stdin (#7668 von @thorn0)

Diese nie offiziell dokumentierte CLI-Option sollte Prettier dazu bringen, Eingaben von stdin zu lesen, was Prettier CLI jedoch bereits tut, wenn keine Dateipfade oder Glob-Muster übergeben werden. Die Option war daher redundant. Nach ihrer Entfernung erscheint bei Verwendung eine Warnung: "Ignored unknown option". Diese Warnung dient lediglich der Information. Sie verhindert weder die korrekte Ausführung des Befehls noch beeinflusst sie den Exit-Code.