Prettier 1.14: YAML-Unterstützung
Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →
Dieses Release fügt YAML-Unterstützung hinzu, ermöglicht Pragma-Kommentare (z.B. /** @prettier */) für alle Sprachen und verbessert die Performance bei großen Dateien. Zusätzlich wurden mehrere neue Syntax-Features implementiert und kleinere Formatierungsoptimierungen vorgenommen, um Ihren Code noch übersichtlicher zu gestalten. ✨
Höhepunkte
YAML
YAML-Unterstützung (#4563, #4742, #4773, #4854 von @ikatyang)
Prettier kann jetzt YAML-Dateien formatieren! 🎉
Die Implementierung folgt strikt der YAML-Spezifikation und nutzt das hervorragende yaml-Paket von @eemeli. Besondere Merkmale:
Zeilenumbruch
Ähnlich wie bei Markdown werden Textpassagen bei 80 Zeichen umgebrochen, sofern dies die Dateisemantik nicht beeinträchtigt.
Eingabe:
>
Voilà! In view, a humble vaudevillian veteran cast vicariously as both victim and villain by the vicissitudes of Fate. This visage, no mere veneer of vanity, is a vestige of the vox populi, now vacant, vanished. However, this valourous visitation of a bygone vexation stands vivified and has vowed to vanquish these venal and virulent vermin vanguarding vice and vouchsafing the violently vicious and voracious violation of volition! The only verdict is vengeance; a vendetta held as a votive, not in vain, for the value and veracity of such shall one day vindicate the vigilant and the virtuous. Verily, this vichyssoise of verbiage veers most verbose, so let me simply add that it’s my very good honour to meet you and you may call me V.
Ausgabe: (--prose-wrap always)
>
Voilà! In view, a humble vaudevillian veteran cast vicariously as both victim
and villain by the vicissitudes of Fate. This visage, no mere veneer of
vanity, is a vestige of the vox populi, now vacant, vanished. However, this
valourous visitation of a bygone vexation stands vivified and has vowed to
vanquish these venal and virulent vermin vanguarding vice and vouchsafing the
violently vicious and voracious violation of volition! The only verdict is
vengeance; a vendetta held as a votive, not in vain, for the value and
veracity of such shall one day vindicate the vigilant and the virtuous.
Verily, this vichyssoise of verbiage veers most verbose, so let me simply add
that it’s my very good honour to meet you and you may call me V.
Hinweis: Die Option
proseWrapist standardmäßig aufpreservegesetzt, daher muss zur Aktivierungalwaysoderneverexplizit angegeben werden.
Teilbereich ignorieren
Um bestimmte Abschnitte einer YAML-Datei von der Formatierung auszunehmen, setzen Sie einfach einen Ignorier-Kommentar davor:
# prettier-ignore
key : value
hello: world
Front Matter
YAML-Front Matter formatieren (#4773 von @ikatyang)
Prettier kann jetzt ----begrenztes YAML-Front Matter in CSS- und Markdown-Dateien verarbeiten:
Eingabe & Ausgabe (Prettier 1.13):
---
key : value
---
# heading
content
Ausgabe (Prettier 1.14):
---
key: value
---
# heading
content
Pragma
requirePragma/insertPragma in allen Sprachen (#4688, #4699, #4713 von @ikatyang)
Prettier 1.7.0 und 1.8.0 führten zwei neue Optionen ein:
--require-pragma und
--insert-pragma.
Bisher waren diese jedoch nur in wenigen Sprachen verfügbar.
Jetzt funktionieren sie in allen Sprachen, inklusive YAML!
-
YAML
# @prettier
key: value -
CSS/Less/SCSS
/** @prettier */
.class {
display: none;
} -
GraphQL
# @prettier
query Browse($offset: Int) {
browse(offset: $offset)
} -
Vue
<!-- @prettier -->
<template>
<div>Template</div>
</template>
JavaScript
Decorators nie einzeilig darstellen (außer bei Parameter-Decorators) (#4830 von @suchipi)
Bisher wurden Decorators stets einzeilig formatiert, da MobX dies als Konvention etablierte. Community-Feedback zeigte jedoch, dass MobX die einzige bedeutende Bibliothek mit dieser Praxis ist. Prettier setzt Decorators jetzt grundsätzlich in eigene Zeilen, es sei denn es handelt sich um Parameter-Decorators.
// Input
@observer
class OrderLine {
@observable
price: number = 0;
@observable amount: number = 1;
foo(@required name) {
console.log(name);
}
}
// Output (Prettier 1.13)
@observer
class OrderLine {
@observable price: number = 0;
@observable amount: number = 1;
foo(@required name) {
console.log(name);
}
}
// Output (Prettier 1.14)
@observer
class OrderLine {
@observable
price: number = 0;
@observable
amount: number = 1;
foo(@required name) {
console.log(name);
}
}
JSX-Leerzeichen getrennt von fbt-Leerzeichen verarbeiten (#4717 von @karl)
Bisher wurde der Leerraum in JSX stets beibehalten,
da Facebook eine eigene Übersetzungspipeline (fbt) verwendet, die JSX-Syntax nutzt, aber Leerraum anders behandelt als reguläres JSX.
Das bedeutete, dass wir den JSX-Leerraum nicht ändern konnten, ohne die Facebook-Codebasis zu beeinträchtigen.
In Prettier 1.14 erkennen wir nun Facebook-fbt-Tags und behandeln den Leerraum für diese anders als bei anderen JSX-Tags,
was die Konsistenz über verschiedene, aber gleichwertige Eingaben hinweg verbessert.
// Input and Output from Prettier 1.13
first = (
<div>
Text<br />
More text<br />
And more<br />
</div>
);
second = (
<div>
Text<br />More text<br />And more<br />
</div>
);
third = (
<div>
Text
<br />
More text
<br />
And more
<br />
</div>
);
// Output from Prettier 1.14
first = (
<div>
Text
<br />
More text
<br />
And more
<br />
</div>
);
second = (
<div>
Text
<br />
More text
<br />
And more
<br />
</div>
);
third = (
<div>
Text
<br />
More text
<br />
And more
<br />
</div>
);
Wenn der Text, der Tags oder Ausdrücke trennt, nur ein einzelnes Zeichen ist, geben wir die gesamte Gruppe, wo möglich, in einer einzigen Zeile aus.
// Input and Output from Prettier 1.13
x = (
<div>
{hour}:{minute}:{second}
</div>
);
x = (
<div>
{hour}
:
{minute}
:
{second}
</div>
);
x = (
<div>
{hour}:
{minute}:
{second}
</div>
);
// Output from Prettier 1.14
x = (
<div>
{hour}:{minute}:{second}
</div>
);
x = (
<div>
{hour}:{minute}:{second}
</div>
);
x = (
<div>
{hour}:{minute}:{second}
</div>
);
Es verbessert auch die Ausgabe von Randfällen wie diesem:
// Input
this_really_should_split_across_lines =
<div>
before{stuff}after{stuff}after{stuff}after{stuff}after{stuff}after{stuff}after{stuff}after
</div>
// Output (Prettier 1.13)
this_really_should_split_across_lines = (
<div>
before{stuff}after{stuff}after{stuff}after{stuff}after{stuff}after{stuff}after{
stuff
}after
</div>
);
// Output (Prettier 1.14)
this_really_should_split_across_lines = (
<div>
before
{stuff}
after
{stuff}
after
{stuff}
after
{stuff}
after
{stuff}
after
{stuff}
after
{stuff}
after
</div>
);
JSX in Pfeilfunktionen innerhalb von JSX-Ausdrücken umbrechen (#4601 von @duailibe)
In früheren Versionen folgte JSX in Pfeilfunktionen innerhalb von JSX-Ausdrücken der allgemeinen Fit-or-Break-Regel, was jedoch bei der Iteration über ein Array weniger lesbar war. Prettier 1.14 erzwingt nun einen Zeilenumbruch bei diesen Pfeilfunktionen, was die Lesbarkeit verbessert.
// Input
const UsersList = ({ users }) => (
<section>
<h2>Users list</h2>
<ul>
{users.map(user => (
<li key={user.id}>{user.name}</li>
))}
</ul>
</section>
)
// Output (Prettier 1.13)
const UsersList = ({ users }) => (
<section>
<h2>Users list</h2>
<ul>{users.map(user => <li key={user.id}>{user.name}</li>)}</ul>
</section>
);
// Output (Prettier 1.14)
const UsersList = ({ users }) => (
<section>
<h2>Users list</h2>
<ul>
{users.map(user => (
<li key={user.id}>{user.name}</li>
))}
</ul>
</section>
);
TypeScript
Unterstützung für TypeScript 3.0 (#4625, #4757 von @ikatyang)
Im kommenden TypeScript 3.0 werden einige neue Funktionen mit neuer Syntax hinzugefügt:
der unknown-Typ und
Tupel in Rest-Parametern und Spread-Ausdrücken.
Prettier 1.14 fügt Unterstützung dafür hinzu, sodass Sie diese formatieren können, sobald TypeScript 3.0 veröffentlicht wird.
// UnknownType
const json: unknown = JSON.parse(jsonText);
// RestType
type Foo = [string, number];
type Bar = [boolean, ...Foo];
// OptionalType
type Baz = [string, number?];
JSON
JSON
Lange Werte in neue Zeilen zu setzen, ist eine Kernfunktion von Prettier, aber wir haben festgestellt, dass dies die Lesbarkeit von Objekten mit langen Zeichenfolgenwerten in JSON-Dateien nicht verbessert. Prettier 1.14 wird den Zeichenfolgenwert eines Objekts nicht verschieben, unabhängig davon, ob er in die Druckbreite passt oder nicht.
// Input
{
"description": "a long long long long long long long long long long long long long long long long long paragraph"
}
// Output (Prettier 1.13)
{
"description":
"a long long long long long long long long long long long long long long long long long paragraph"
}
// Output (Prettier 1.14)
{
"description": "a long long long long long long long long long long long long long long long long long paragraph"
}
Markdown
Listen nur ausrichten, wenn sie bereits ausgerichtet sind (#4893 von @ikatyang)
Bisher haben wir Listen immer ausgerichtet, um eine bessere Einrückung zu erreichen und als Problemumgehung für falsch geparste eingerückte Codeblöcke. Dies führte jedoch zu doppelten Leerzeichen vor geordneten Listen, was in Markdown unüblich ist. In Prettier 1.14 richten wir Listen nur noch in folgenden Fällen aus:
-
Sie sind bereits ausgerichtet.
-
Vor dem ersten Listenelement stehen mindestens zwei Leerzeichen.
-
Darin befindet sich ein eingerückter Codeblock.
Eingabe:
1. 123
1. 123
---
1. 123
1. 123
---
11. 123
1. 123
---
11. 123
1. 123
---
1. 123
1. 123
Ausgabe: (Prettier 1.13)
1. 123
1. 123
---
1. 123
1. 123
---
11. 123
1. 123
---
11. 123
1. 123
---
1. 123
1. 123
Ausgabe: (Prettier 1.13)
1. 123
1. 123
---
1. 123
1. 123
---
11. 123
1. 123
---
11. 123
1. 123
---
1. 123
1. 123
Ausgabe: (Prettier 1.14)
Leistung
Eine Kernfunktion von Prettier ist es, Zeilen umzubrechen, wenn sie die Druckbreite überschreiten.
Dazu müssen wir die visuelle Breite jedes Zeichens berechnen.
Der einfachste Weg, dies zu zählen, ist die Verwendung der JavaScript-Eigenschaft String#length.
Einige Nicht-ASCII-Zeichen wie CJK-Zeichen haben jedoch eine Breite, die größer ist als die eines lateinischen Zeichens.
Als Problemumgehung haben wir diese 2 Zeichen breiten Zeichen vor der Berechnung der Zeichenkettenlänge durch zwei Leerzeichen ersetzt.
Das funktioniert gut, verlangsamt aber auch Prettier, weil wir den Ersetzungsvorgang für jedes Token durchführen müssen.
In Prettier 1.14 prüfen wir, ob die Zeichenkette nur ASCII-Zeichen enthält,
sodass wir unnötige Zeichenkettenersetzung vermeiden können.
Dies führt zu einer 20%igen Beschleunigung bei großen Dateien.
Weitere Änderungen
API/CLI
Unterstützung relativer Pfade für plugins und pluginSearchDirs in Konfigurationsdateien (#4667 von @ikatyang)
In Prettier 1.13 führten wir die Option pluginSearchDirs ein, die festlegt, wo Prettier nach Plugins sucht.
Sie funktionierte gut bei Angabe in der CLI, da sie immer relativ zum aktuellen Verzeichnis war,
aber relative Pfade in Konfigurationsdateien waren nicht möglich.
In Prettier 1.14 werden nun relative Pfade für pluginSearchDirs und plugins in Konfigurationsdateien unterstützt.
Kein Fehler mehr, wenn prettier in einem Verzeichnis installiert ist, das nicht prettier heißt (#4706 von @asottile)
In Prettier 1.13 fügten wir Unterstützung für global installierte Plugins hinzu, indem wir im Verzeichnisbaum
nach dem nächsten node_modules ab prettier suchten. Wir gingen davon aus, dass immer ein prettier-Verzeichnis
existiert – was zu Abstürzen führte, wenn es anders benannt war.
In Prettier 1.14 haben wir die Suchlogik geändert, sodass Sie das prettier-Verzeichnis bei Bedarf umbenennen können
(zum Beispiel beim Veröffentlichen eines Forks auf npm).
Unterstützung für filepath im Browser (#4721 von @ikatyang)
In Prettier 1.13 fügten wir First-Class-Unterstützung für die Ausführung im Browser hinzu, aber der einzige Weg,
den Parser auszuwählen, war die parser-Option. Prettier 1.14 unterstützt nun die filepath-Option in der Browser-API,
wodurch Prettier den Parser automatisch ermitteln kann – genau wie in der Node.js-API.
Dies ist besonders nützlich für Web-Editor-Anwendungen!
Verfügbarmachen von isPreviousLineEmpty für Plugins (#4748 von @warrenseine)
Bisher machten wir isNextLineEmpty für Plugins verfügbar, aber nicht isPreviousLineEmpty.
Prettier 1.14 macht es verfügbar, da es für Szenarien wie Direktiven in C# nützlich sein kann.
JavaScript
Unterstützung für BigInt-Literale (#4697 von @ikatyang)
BigInt-Literale werden nun im Standardparser babylon unterstützt.
const bigInt = 1n;
Unterstützung für throw-Ausdrücke (#4695 von @VojtechStep)
Throw-Ausdrücke werden nun im Standardparser babylon unterstützt.
const assert = x => x || throw new Error('...');
Immer ersten Parameter erweitern, wenn zweiter Parameter ebenfalls ein Aufrufausdruck ist (#4657 von @duailibe)
Bisher gab es eine Sonderregel, Funktionsaufrufe nicht umzubrechen,
wenn nur zwei Parameter übergeben wurden und der erste eine Funktion war.
Das funktionierte gut, aber wenn der zweite Parameter ebenfalls eine Funktion war, sah es nicht optimal aus.
// Input
somePromise.then((args) => {
this.props.receiveFavoritesActions(id, [].concat(...args));
}, ({ isCanceled }) => !isCanceled && logger.warn(`Error getting actions for the product: ${id}`));
// Output (Prettier 1.13)
somePromise.then(args => {
this.props.receiveFavoritesActions(id, [].concat(...args));
}, ({ isCanceled }) => !isCanceled && logger.warn(`Error getting actions for the product: ${id}`));
// Output (Prettier 1.14)
somePromise.then(
args => {
this.props.receiveFavoritesActions(id, [].concat(...args));
},
({ isCanceled }) =>
!isCanceled && logger.warn(`Error getting actions for the product: ${id}`)
);
Klammern für await in Bind-Syntax hinzufügen (#4778 von @ikatyang)
Bisher entfernte Prettier fälschlich notwendige Klammern für await in der experimentellen Bind-Syntax,
was die Bedeutung veränderte. Prettier 1.14 bewahrt die Klammern nun korrekt.
// Input
const doBothThings = async () => {
const request = doAsyncThing();
return (await request)::doSyncThing();
};
// Output (Prettier 1.13)
const doBothThings = async () => {
const request = doAsyncThing();
return await request::doSyncThing(); // means `await (request::doSyncThing)`
};
// Output (Prettier 1.14)
const doBothThings = async () => {
const request = doAsyncThing();
return (await request)::doSyncThing();
};
super und await auf oberster Ebene erlauben (#4823 von @ikatyang)
super und await dürfen nicht außerhalb von Klassen bzw. Async-Funktionen stehen,
aber unsere Range-Formatierung funktionierte nicht korrekt bei der Auswahl von Funktionsinhalten.
Prettier 1.14 erlaubt sie nun überall.
super();
await doSomething();
this und super in Heuristiken für funktionale Komposition auf Blacklist setzen (#4836 von @princed)
In Prettier 1.13 haben wir die Formatierung von Funktionen für funktionale Komposition (z. B. pipe, compose usw.) verbessert, indem wir ihre Parameter in eigene Zeilen gesetzt haben. Dies führte jedoch zu falsch positiven Ergebnissen bei Funktionen mit gleichem Namen in Klassen. Prettier 1.14 schließt this und super in den Heuristiken für funktionale Komposition aus.
// Input
class X {
x() {
this.compose(a(), b);
super.compose(a(), b);
}
}
// Output (Prettier 1.13)
class X {
x() {
this.compose(
a(),
b
);
super.compose(
a(),
b
);
}
}
// Output (Prettier 1.14)
class X {
x() {
this.compose(a(), b);
super.compose(a(), b);
}
}
TypeScript
Unterstützung für import.meta (#4762 von @ikatyang)
In Prettier 1.13 unterstützte die verwendete TypeScript-Parser-Version das Parsen der import.meta-Syntax nicht. Wir haben unseren TypeScript-Parser in Prettier 1.14 aktualisiert, sodass sie nun korrekt geparst und formatiert werden.
console.log(import.meta.url);
Optionale Eigenschaft mit StringLiteral-Schlüssel in Klassen (#4762 von @ikatyang)
In der vorherigen Version wurde das ? bei optionalen Eigenschaften mit String-Literal als Schlüssel fälschlicherweise entfernt. Wir haben diesen Fehler in Prettier 1.14 behoben, sodass es nicht mehr entfernt wird.
// Input
export class ClassExample {
"a-prop"?: boolean;
}
// Output (Prettier 1.13)
export class ClassExample {
"a-prop": boolean;
}
// Output (Prettier 1.14)
export class ClassExample {
"a-prop"?: boolean;
}
Fehler bei mehreren Superklassen in einer Klasse werfen (#4762 von @ikatyang)
Klassen dürfen nur eine Elternklasse haben, aber der TypeScript-AST erlaubt mehrere, da die extends-Klausel intern dieselbe Struktur hat wie die implements-Klausel. Zuvor wurden zusätzliche Superklassen stillschweigend während des Ausdrucks entfernt, was nach der Formatierung zu Verwirrung führen konnte. In Prettier 1.14 werden sie stattdessen als Syntaxfehler markiert.
// Input
class Foo extends BarComponent, BazService, QuuxProvider {}
// Output (Prettier 1.13)
class Foo extends BarComponent {}
// Output (Prettier 1.14)
/*
SyntaxError: Classes can only extend a single class.
*/
Unterstützung für JSX-Spread-Kind (#4885 von @ikatyang)
Zuvor wurden die ... in Kind-Spreads von JSX-Ausdrücken fälschlicherweise entfernt. Wir haben dieses Problem in Prettier 1.14 behoben.
// Input
const x = <div>{...[0]}</div>
// Output (Prettier 1.13)
const x = <div>{[0]}</div>;
// Output (Prettier 1.14)
const x = <div>{...[0]}</div>;
Flow
Unterstützung für die Erweiterung .js.flow (#4777 von @ikatyang)
Die Erweiterung .js.flow für Flow-Deklarationsdateien wurde zuvor nicht erkannt. In Prettier 1.14 werden sie automatisch erfasst, sodass Sie keine Überschreibungen in Konfigurationsdateien hinzufügen müssen.
CSS/Less/SCSS
Korrekte Behandlung von Zeilenumbrüchen zwischen Front-Matter und Kommentar (#4701 von @evilebottnawi)
Mehrere Zeilenumbrüche zwischen Front-Matter und CSS-Kommentar wurden in Prettier 1.13 durch ein Leerzeichen ersetzt. In Prettier 1.14 setzen wir stattdessen einen Zeilenumbruch zwischen sie.
/* Input */
---
key: value
---
/* comment */
.class {
display: none;
}
/* Output (Prettier 1.13) */
---
key: value
---
/* comment */
.class {
display: none;
}
/* Output (Prettier 1.14) */
---
key: value
---
/* comment */
.class {
display: none;
}
Unterstützung für At-Regeln mit schließender geschweifter Klammer (#4733 von @davidgomes)
In der vorherigen Version wurden At-Regeln, die mit } endeten, nicht korrekt geparst. Prettier 1.14 erkennt und formatiert sie nun richtig.
/* Input */
@mixin placeholder {
&::placeholder {@content}
}
/* Output (Prettier 1.13) */
/*
SyntaxError: CssSyntaxError Unclosed block
*/
/* Output (Prettier 1.14) */
@mixin placeholder {
&::placeholder {
@content;
}
}
Markdown
Erhalt von E-Mail-Autolinks (#4740 von @ikatyang)
Autolinks wurden in der vorherigen Version als ihre URL formatiert, was in Ordnung ist. Es gibt jedoch einen Sonderfall bei E-Mail-Links, die als mailto:-Links aufgelöst werden. In Prettier 1.14 bleiben E-Mail-Autolinks erhalten.
<!-- Input -->
<hello@example.com>
<!-- Output (Prettier 1.13) -->
<mailto:hello@example.com>
<!-- Output (Prettier 1.14) -->
<hello@example.com>
Kein Leerzeichen nach Markdown-Block-Sprachnamen erforderlich (#4783 von @kachkaev)
In Prettier 1.12 fügten wir Unterstützung für eingezäunte Codeblöcke mit Sprachnamen hinzu, gefolgt von Attributen, die durch Leerzeichen getrennt sein müssen. Dies führte jedoch zu Inkonsistenzen bei der Codeblock-Hervorhebung in Atom, wo Codeblöcke hervorgehoben, aber nicht von uns formatiert wurden. Wir haben unsere Erkennungslogik in Prettier 1.14 aktualisiert, sodass sie sich nun gleich verhalten sollten.
<!-- Input -->
```js{something=something}
const x = 1;
```
<!-- Output (Prettier 1.13) -->
```js{something=something}
const x = 1;
```
<!-- Output (Prettier 1.14) -->
```js{something=something}
const x = 1;
```
Verwendung von Sprachaliasen zum Finden des Parsers für Markdown-Codeblöcke (#4734 von @ikatyang)
Bisher verwendeten wir den name und die extensions der Sprache, um den Parser für die Codeblock-Formatierung zu bestimmen.
Wir stellten jedoch fest, dass es unmöglich ist, JSON with Comments-Codeblöcke zu formatieren und gleichzeitig die Syntaxhervorhebung beizubehalten,
da sie dieselbe .json-Erweiterung wie JSON verwenden und die Kommentar-Syntaxhervorhebung nur in JSON5 verfügbar ist.
In Prettier 1.14 haben wir die Unterstützung für die Verwendung von Sprach-aliases zur Parser-Suche hinzugefügt.
Daher sollten Sie jsonc verwenden können, um die Formatierung und Syntaxhervorhebung für JSON with Comments-Codeblöcke auszulösen.
<!-- Input -->
```jsonc
// comment
{"a":1}
```
<!-- Output (Prettier 1.13) -->
```jsonc
// comment
{"a":1}
```
<!-- Output (Prettier 1.14) -->
```jsonc
// comment
{ "a": 1 }
```
Beibehalten der Entität für kodierte Zeichen, wenn ihr Codepoint größer als U+FFFF ist (#4832 by @ikatyang)
Der von uns verwendete Markdown-Parser (remark) analysiert jedes kodierte Zeichen in einen einzelnen AST-Knoten,
sodass wir das kodierte Zeichen wiederherstellen können, indem wir prüfen, ob der Wert im AST-Knoten eine Länge von 1 hat.
Es gibt jedoch eine Ausnahme: Ein einzelnes Zeichen kann eine Länge von 2 haben, wenn sein Codepoint größer als 0xFFFF ist,
da JavaScript UTF-16 (2 Bytes) zur Zeichenkodierung verwendet.
Prettier 1.14 erkennt diese Zeichen korrekt, sodass sie nicht in das Literalzeichen umgewandelt werden.
<!-- Input -->
😉
<!-- Output (Prettier 1.13) -->
😉
<!-- Output (Prettier 1.14) -->
😉
Vue
Unterstützung der Bereichsformatierung für Vue-Dateien (#4868 by @ikatyang)
Bisher war die Bereichsformatierung in Vue nicht verfügbar, aber Prettier 1.14 fügt diese Unterstützung hinzu.
GraphQL
Beibehalten von Zeilenumbrüchen in nicht blockierten String-Werten (#4808 by @ikatyang)
Nicht blockierte String-Werte dürfen nur in einer einzigen Zeile stehen,
aber Prettier 1.13 wandelte fälschlicherweise das maskierte \n in einen echten Zeilenumbruch um.
Prettier 1.14 gibt nun korrekt \n aus.
# Input
{
foo(input: {multiline: "ab\ncd"}) { id }
}
# Output (Prettier 1.13)
{
foo(input: { multiline: "ab
cd" }) {
id
}
}
# Output (Prettier 1.14)
{
foo(input: { multiline: "ab\ncd" }) {
id
}
}
