Zum Hauptinhalt springen

Prettier 1.18: Zahlreiche Korrekturen und OpenCollective

· 10 Min. Lesezeit
Inoffizielle Beta-Übersetzung

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

Diese Version enthält keine neuen Funktionen, dafür aber viele Korrekturen für JavaScript, insbesondere JSX und Template Literals, TypeScript und Markdown.

Außerdem möchten wir daran erinnern, dass Prettier jetzt Spenden annimmt! Wenn Sie Prettier nutzen und unsere Arbeit unterstützen möchten, besuchen Sie unsere OpenCollective.

Höhepunkte

JavaScript

Einfache Template Literals nicht mehr umbrechen (#5979 by @jwbay)

Dieser Aspekt von Prettier führt häufig zu Änderungswünschen: das Umbrechen einfacher Ausdrücke in Template Literals. Bisher hat Prettier die Ausdrücke in mehrere Zeilen umgebrochen, wenn das gesamte Literal die Druckbreite überschritt. Jetzt verhindern wir den Umbruch, wenn der Ausdruck einfach ist.

Dies ist eine Verbesserung gegenüber der vorherigen Lösung, aber es bleibt noch Arbeit in diesem Bereich.

// Input
console.log(chalk.white(`Covered Lines below threshold: ${coverageSettings.lines}%. Actual: ${coverageSummary.total.lines.pct}%`))

// Output (Prettier stable)
console.log(
chalk.white(
`Covered Lines below threshold: ${coverageSettings.lines}%. Actual: ${
coverageSummary.total.lines.pct
}%`
)
);

// Output (Prettier master)
console.log(
chalk.white(
`Covered Lines below threshold: ${coverageSettings.lines}%. Actual: ${coverageSummary.total.lines.pct}%`
)
);

Leere JSX-Elemente nicht mehr in selbstschließende Elemente umwandeln (#6127 by @duailibe)

Prettier hat leere JSX-Elemente (<div></div>) stets in selbstschließende Elemente (<div />) umgewandelt, da diese äquivalent sind.

Wir haben Rückmeldungen erhalten, dass man während der Entwicklung öffnende und schließende Tags schreiben und diese leer lassen möchte, um später Kinder hinzuzufügen. Prettier wandelte sie jedoch in selbstschließende Elemente um, was Entwickler zwang, sie manuell zurückzuändern. Dies wurde in dieser Version geändert.

// Input
function Foo() {
return <div></div>;
}

// Output (Prettier stable)
function Foo() {
return <div />;
}

// Output (Prettier master)
function Foo() {
return <div></div>;
}

Weitere Änderungen

JavaScript

Typecasts im Closure Compiler korrigieren (#5947 by @jridgewell)

Folgt auf einen Typecast in einem inneren Ausdruck eine schließende Klammer, würde der Typecast alles bis zu dieser Klammer umschließen.

// Input
test(/** @type {!Array} */(arrOrString).length);
test(/** @type {!Array} */((arrOrString)).length + 1);
// Output (Prettier stable)
test(/** @type {!Array} */ (arrOrString.length));
test(/** @type {!Array} */ (arrOrString.length + 1));
// Output (Prettier master)
test(/** @type {!Array} */ (arrOrString).length);
test(/** @type {!Array} */ (arrOrString).length + 1);

Closure-Typecasts ohne Leerzeichen korrigieren (#6116 by @jridgewell)

Bisher war ein Leerzeichen zwischen @type und der öffnenden { eines Closure-Typecasts erforderlich, andernfalls wurden die umschließenden Klammern entfernt. Closure selbst erfordert kein Leerzeichen.

// Input
const v = /** @type{string} */(value);

// Output (Prettier stable)
const v = /** @type{string} */ value;

// Output (prettier master)
const v = /** @type{string} */ (value);

Keine unnötigen Anführungszeichen bei --quote-props=consistent und Objekten mit numerischen oder berechneten Schlüsseln (#6119 und #6138 by @duailibe)

Bisher fügte Prettier unnötige Anführungszeichen zu Schlüsseln eines Objekts oder zu Eigenschaften und Methoden von Klassen hinzu, wenn mindestens ein berechneter Schlüssel mit "komplexem" Ausdruck (z.B. Member-Ausdruck) oder ein numerisches Literal vorhanden war.

// Input
const obj = {
foo: "",
[foo.bar]: "",
};

const other = {
foo: "",
1: ""
};

// Output (Prettier stable)
const obj = {
"foo": "",
[foo.bar]: "",
};

const other = {
"foo": "",
1: ""
};

// Output (Prettier master)
const obj = {
foo: "",
[foo.bar]: "",
};

const other = {
foo: "",
1: ""
};

Klammern bei JSX-Spread-Elementen mit logischen Ausdrücken hinzufügen (#6130 by @duailibe)

Bisher fügte Prettier keine Klammern bei JSX-Spread-Elementen hinzu, da diese nicht notwendig sind. Der Konsistenz mit dem Spread-Operator in Objekten und Arrays zuliebe werden wir sie nun auch für JSX hinzufügen.

// Input
<Component {...(props || {})} />;

// Output (Prettier stable)
<Component {...props || {}} />;

// Output (Prettier master)
<Component {...(props || {})} />;

Kommentare in leeren Pfeilfunktionsausdrücken korrekt behandeln (#6086 by @evilebottnawi)

// Input
const fn = (/*event, data*/) => doSomething(anything);

// Output (Prettier stable)
const fn = () => /*event, data*/ doSomething(anything);

// Output (Prettier master)
const fn = (/*event, data*/) => doSomething(anything);

Sequenzausdrücke in Objekteigenschaften nicht mehr zusammenziehen (#6088 by @evilebottnawi)

// Input
const a = {
someKey:
(longLongLongLongLongLongLongLongLongLongLongLongLongLongName, shortName)
};

// Output (Prettier stable)
const a = {
someKey: (longLongLongLongLongLongLongLongLongLongLongLongLongLongName,
shortName)
};

// Output (Prettier master)
const a = {
someKey:
(longLongLongLongLongLongLongLongLongLongLongLongLongLongName, shortName)
};

Unterstützung für externe Styles in styled-jsx hinzufügen (#6089 by @hongrich)

Unterstützung für 2 externe Style-Tags in styled-jsx/css hinzugefügt: css.global und css.resolve. https://github.com/zeit/styled-jsx/#external-css-and-styles-outside-of-the-component

Das css-Template-Tag wird bereits von Prettier unterstützt.

// Input
const styles = css.resolve`
.box {background:black;
}`;

// Output (Prettier stable)
const styles = css.resolve`
.box {background:black;
}`;

// Output (prettier master)
const styles = css.resolve`
.box {
background: black;
}
`;

Klammern um Funktionen und Klassen in export default-Deklarationen beibehalten (#6133 by @duailibe)

Prettier entfernte Klammern von einigen Ausdrücken in export default, aber wenn es sich um komplexe Ausdrücke handelt, die mit function oder class beginnen, sind die Klammern erforderlich.

Nachfolgend finden Sie einige praktische Beispiele, darunter eines, das TypeScript betrifft.

// Input
export default (function log() {}).toString();
export default (function log() {} as typeof console.log);

// Output (Prettier stable)
export default function log() {}.toString();
export default function log() {} as typeof console.log; // syntax error

// Output (Prettier master)
export default (function log() {}).toString();
export default (function log() {} as typeof console.log);

Behebung von Klammerungsfehlern in Randfällen bei Aufrufen und new (#6148 von @bakkot)

Das Hinzufügen aller und nur der notwendigen Klammern beim Kombinieren von new mit Funktionsaufrufen ist knifflig. Diese Änderung behebt zwei Fälle, in denen notwendige Klammern fehlten, und einen Fall, in dem überflüssige Klammern hinzugefügt wurden.

// Input
new (x()``.y)();
new (x()!.y)();
new e[f().x].y()

// Output (Prettier stable)
new x()``.y();
new x()!.y();
new e[(f()).x].y();

// Output (Prettier master)
new (x())``.y();
new (x())!.y();
new e[f().x].y();

Behebung verschachtelter Einbettungen (JS in HTML in JS) (#6038 von @thorn0)

Zuvor wurde verschachtelter JS-Code (via Template-Literal in JS eingebettet, der HTML mit <script>-Tags enthielt) nicht formatiert, wenn er Template-Literale enthielt.

// Input
const html = /* HTML */ `<script>var a=\`\`</script>`;

// Output (Prettier stable)
// SyntaxError: Expecting Unicode escape sequence \uXXXX (1:8)

// Output (Prettier master)
const html = /* HTML */ `
<script>
var a = \`\`;
</script>
`;

Notwendige Klammern um Bind-Ausdrücke in new-Ausdrücken beibehalten (#6152 von @sosukesuzuki)

Zuvor entfernte Prettier notwendige Klammern um Bind-Ausdrücke, wenn diese an new-Ausdrücke übergeben wurden.

// Input
new (a::b)();

// Output (Prettier stable)
new a::b();

// Output (Prettier master)
new (a::b)();

Vermeidung überflüssiger Klammern um Bind-Ausdrücke in Eigenschaften von Member-Ausdrücken (#6159 von @duailibe)

// Input
f[a::b];

// Output (Prettier stable)
f[(a::b)];

// Output (Prettier master);
f[a::b];

TypeScript

Nachgestelltes Komma in TSX-Typparametern beibehalten (#6115 von @sosukesuzuki)

Zuvor wurde ein nachgestelltes Komma nach einzelnen Typparametern in Pfeilfunktionen entfernt. Das formatierte Ergebnis war in TypeScript gültig, aber in TSX ungültig. Dies wurde in Version 1.19 behoben.

// Input
type G<T> = any;
const myFunc = <T,>(arg1: G<T>) => false;

// Output (Prettier stable)
type G<T> = any;
const myFunc = <T>(arg1: G<T>) => false;

// Output (prettier master)
type G<T> = any;
const myFunc = <T,>(arg1: G<T>) => false;

Vermeidung des Aufbrechens von Aufrufausdrücken bei Pfeilfunktionen mit einfachem Rückgabetyp als letztem Argument (#6106 von @brainkim)

Behebt einen Randfall, bei dem Aufrufausdrücke mit Pfeilfunktionen mit einfachen Rückgabetypen aufgeteilt wurden.

app.get("/", (req, res): void => {
res.send("Hello World!");
});

// Output (Prettier stable)
app.get(
"/",
(req, res): void => {
res.send("Hello World!");
},
);

// Output (Prettier master)
app.get("/", (req, res): void => {
res.send("Hello World!");
});

Klammerpaar bei überzähligen Klammern beibehalten (#6131 von @sosukesuzuki)

Zuvor entfernte Prettier in TypeScript notwendige Klammern beim Versuch, überflüssige Klammern zu entfernen.

// Input
type G = ((keyof T))[];

// Output (Prettier stable)
type G = keyof T[];

// Output (prettier master)
type G = (keyof T)[];

Notwendige Klammern um Non-Null-Assertions beibehalten (#6136 von @sosukesuzuki, #6140 von @thorn0, #6148 von @bakkot)

Zuvor entfernte Prettier notwendige Klammern um Non-Null-Assertions, wenn das Ergebnis des Assertions-Ausdrucks als Konstruktor aufgerufen wurde.

// Input
const b = new (c()!)();

// Output (Prettier stable)
const b = new c()!();

// Output (Prettier master)
const b = new (c())!();

Zeilenumbrüche innerhalb von Mapped Types beibehalten (#6146 von @sosukesuzuki)

Zuvor entfernte Prettier Zeilenumbrüche innerhalb von Mapped Types. Um dies analog zu Objektliteralen zu gestalten, werden Zeilenumbrüche beibehalten, wenn sie im Quellcode vorhanden waren.

// Input
type A<T> = {
readonly [P in keyof T]: T[P];
};

// Output (Prettier stable)
type A<T> = { readonly [P in keyof T]: T[P] };

// Output (Prettier master)
type A<T> = {
readonly [P in keyof T]: T[P];
};

Nachgestelltes Komma bei Tupeltypen mit --trailing-comma=all hinzufügen (#6172 von @sosukesuzuki)

TypeScript unterstützt seit Version 3.3 ein nachgestelltes Komma bei Tupeltypen.

// Input
export type Foo = [
number,
number, // comment
];

// Output (Prettier stable)
export type Foo = [
number,
number // comment
];

// Output (Prettier master);
export type Foo = [
number,
number, // comment
];

Markdown

Korrekte Bestimmung der Backtick-Anzahl in Inline-Code (#6110 von @belochub)

Laut CommonMark-Spezifikation muss "eine Zeichenkette von n Backtick-Zeichen als Begrenzer gewählt werden, wobei der Code keine Zeichenketten mit genau n Backtick-Zeichen enthält".

Die Methode zur Ermittlung der benötigten Backtick-Anzahl wurde geändert: Statt pauschal 2 Backticks (bei einzelnen Backticks im Codeblock) oder 1 Backtick zu verwenden, wird nun die minimale Länge ermittelt, die korrekt als Begrenzer fungieren kann.

<!-- Input -->
``` 3 ``22`` `1` ```

`` 2 ```123``` `1` ``

<!-- Output (Prettier stable) -->
` 3 ``22`` `1` `

` 2 ```123``` `1` `

<!-- Output (Prettier master) -->
``` 3 ``22`` `1` ```

`` 2 ```123``` `1` ``

Handlebars

Während die Handlebars-Unterstützung noch in der Beta-Phase ist, veröffentlicht @GavinJoyce Korrekturen für den Weg zur stabilen Version.

Vermeidung unerwünschter Leerzeichen nach Komponenten (#6178 von @GavinJoyce)

Zuvor fügte Prettier ein Leerzeichen vor /> und einen Zeilenumbruch danach ein, selbst bei neuen Zeilen. Diese überflüssigen Elemente sind nun entfernt.

// Input
<div>
<UserGreeting
@aVeryLongArgumentNameThatIsStillGoing={{@alsoAVeryLongArgument}}
/>
</div>

// Output (Prettier stable)
<div>
<UserGreeting
@aVeryLongArgumentNameThatIsStillGoing={{@alsoAVeryLongArgument}}
/>

</div>

// Output (Prettier master)
<div>
<UserGreeting
@aVeryLongArgumentNameThatIsStillGoing={{@alsoAVeryLongArgument}}
/>
</div>

API

Prettier funktioniert jetzt wieder in Atom (#6129 von @duailibe)

Atom verfügt über eine Sicherheitsfunktion, die die Ausführung von Code mit eval verbietet. Eine Abhängigkeit von Prettier verwendete eval, um zu verhindern, dass Bundler Debug-Code einbinden. Wir haben sichergestellt, dass dieses eval nicht im an npm ausgelieferten Code enthalten ist, sodass Prettier wieder problemlos mit Atom funktioniert.