Prettier 1.14 : Prise en charge du YAML
Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →
Cette version ajoute la prise en charge du YAML, des pragmas (c'est-à-dire /** @prettier */) pour tous les langages, et améliore les performances sur les fichiers volumineux. Elle ajoute également la prise en charge de plusieurs nouvelles fonctionnalités syntaxiques, ainsi que quelques ajustements de formatage pour rendre votre code encore plus élégant. ✨
Principales fonctionnalités
YAML
Prise en charge du YAML (#4563, #4742, #4773, #4854 par @ikatyang)
Prettier peut désormais formater les fichiers YAML ! 🎉
L'implémentation est très conforme à la spécification YAML, et s'appuie sur l'excellent package yaml grâce à @eemeli. Quelques points forts :
Retour à la ligne
Comme pour Markdown, nous forcerons le retour à la ligne à 80 caractères pour le texte en prose, sauf si cela affecte le sens du fichier.
Entrée :
>
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.
Sortie : (--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.
Note : l'option
proseWrapest définie surpreservepar défaut, vous devrez donc spécifieralwaysouneverpour activer cette fonctionnalité.
Ignorer une partie du fichier
Si vous ne souhaitez pas formater une partie du fichier YAML pour une raison quelconque, vous pouvez toujours ajouter un commentaire d'ignorage avant celle-ci :
# prettier-ignore
key : value
hello: world
Front Matter
Formater le front matter YAML (#4773 par @ikatyang)
Prettier peut désormais formater le front matter YAML délimité par --- dans les fichiers CSS et Markdown :
Entrée & Sortie (Prettier 1.13) :
---
key : value
---
# heading
content
Sortie (Prettier 1.14) :
---
key: value
---
# heading
content
Pragma
Prise en charge de requirePragma/insertPragma pour tous les langages (#4688, #4699, #4713 par @ikatyang)
Prettier 1.7.0 et 1.8.0 ont introduit deux nouvelles options : --require-pragma et --insert-pragma. Cependant, ces options n'étaient prises en charge que pour quelques langages. Désormais, elles sont disponibles pour tous les langages, y compris le 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
Ne jamais inliner les décorateurs sauf s'ils sont des décorateurs de paramètres isolés (#4830 par @suchipi)
Auparavant, les décorateurs étaient toujours inlinés car MobX les inlinait par convention, mais des retours de la communauté nous ont amenés à découvrir que MobX est la seule bibliothèque majeure suivant cette convention. Prettier place désormais les décorateurs sur leurs propres lignes, sauf s'il s'agit de décorateurs de paramètres.
// 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);
}
}
Gérer les espaces JSX séparément des espaces fbt (#4717 par @karl)
Auparavant, les espaces JSX étaient toujours préservés car Facebook dispose d'un pipeline de traduction personnalisé (fbt) utilisant la syntaxe JSX mais traitant les espaces différemment du JSX standard. Cela empêchait toute modification des espaces JSX sans casser la base de code de Facebook. Dans Prettier 1.14, nous détectons désormais les tags fbt de Facebook et traitons leurs espaces différemment des autres tags JSX, améliorant ainsi la cohérence entre différentes entrées équivalentes.
// 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>
);
Lorsque le texte séparant les tags ou expressions ne fait qu'un seul caractère, nous imprimons l'ensemble sur une seule ligne lorsque possible.
// 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>
);
Cela améliore également la sortie dans des cas limites comme celui-ci :
// 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>
);
Casser le JSX dans les fonctions fléchées des expressions JSX (#4601 par @duailibe)
Dans les versions précédentes, le JSX dans les fonctions fléchées des expressions JSX suivait la règle générale d'ajustement ou de cassure, mais cela nuisait à la lisibilité lors de l'itération sur un tableau. Prettier 1.14 force la cassure de ces fonctions fléchées, améliorant ainsi la lisibilité.
// 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
Prise en charge de TypeScript 3.0 (#4625, #4757 par @ikatyang)
Quelques nouvelles fonctionnalités incluant une nouvelle syntaxe sont ajoutées dans TypeScript 3.0 : le type unknown et les tuples dans les paramètres rest et expressions spread. Prettier 1.14 ajoute leur prise en charge pour vous permettre de les formater lorsque TypeScript 3.0 sera publié.
// UnknownType
const json: unknown = JSON.parse(jsonText);
// RestType
type Foo = [string, number];
type Bar = [boolean, ...Foo];
// OptionalType
type Baz = [string, number?];
JSON
Ne pas placer les valeurs sur une ligne séparée de la clé (#4852 par @ikatyang)
Placer les valeurs longues sur de nouvelles lignes est une fonctionnalité centrale de Prettier, mais nous avons constaté que cela n'améliore pas la lisibilité pour les objets contenant de longues chaînes de caractères dans les fichiers JSON. Prettier 1.14 ne déplacera pas les valeurs de chaînes d'un objet, qu'elles respectent ou non la largeur d'impression.
// 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
Aligner les listes uniquement si elles le sont déjà (#4893 par @ikatyang)
Auparavant, nous alignions toujours les listes pour une meilleure expérience d'indentation et comme contournement pour le mauvais parsing des blocs de code indentés, mais cela introduisait des doubles espaces devant les listes ordonnées, ce qui n'est pas courant en markdown. Dans Prettier 1.14, nous n'alignons les listes que dans les cas suivants :
-
Elles sont déjà alignées.
-
Il y a au moins deux espaces devant le premier élément de liste.
-
Un bloc de code indenté est présent à l'intérieur.
Entrée :
1. 123
1. 123
---
1. 123
1. 123
---
11. 123
1. 123
---
11. 123
1. 123
---
1. 123
1. 123
Sortie : (Prettier 1.13)
1. 123
1. 123
---
1. 123
1. 123
---
11. 123
1. 123
---
11. 123
1. 123
---
1. 123
1. 123
Sortie : (Prettier 1.14)
1. 123
1. 123
---
1. 123
1. 123
---
11. 123
1. 123
---
11. 123
1. 123
---
1. 123
1. 123
Performances
Amélioration des performances sur les gros fichiers (#4790, #4848 par @sompylasar)
La fonctionnalité principale de Prettier est d'effectuer des retours à la ligne lorsque la largeur d'impression est dépassée, ce qui nécessite de calculer la largeur visuelle de chaque caractère. La méthode la plus simple pour les compter est d'utiliser la propriété String#length de JavaScript, mais certains caractères non-ASCII comme les caractères CJK ont une largeur supérieure à un caractère latin. Pour contourner ce problème, nous remplacions ces caractères de 2 caractères de large par 2 espaces avant de calculer la longueur de la chaîne. Cela fonctionnait bien mais ralentissait Prettier car nous devions exécuter le remplacement sur chaque jeton. Dans Prettier 1.14, nous vérifions si la chaîne ne contient que des caractères ASCII pour éviter les remplacements inutiles. Cela se traduit par une accélération de 20 % sur les gros fichiers.
Autres changements
API/CLI
Prise en charge des chemins relatifs pour plugins et pluginSearchDirs dans les fichiers de configuration (#4667 par @ikatyang)
Dans Prettier 1.13, nous avons introduit l'option pluginSearchDirs qui modifie l'emplacement où Prettier recherche les plugins.
Elle fonctionnait bien via la CLI car toujours relative au répertoire courant,
mais les chemins relatifs ne fonctionnaient pas dans les fichiers de configuration.
Avec Prettier 1.14, les chemins relatifs pour pluginSearchDirs et plugins sont désormais pris en charge dans les fichiers de configuration.
Ne plus générer d'erreur si prettier est installé dans un répertoire non nommé prettier (#4706 par @asottile)
Nous avions ajouté la prise en charge des plugins installés globalement dans Prettier 1.13 en remontant l'arborescence
pour trouver le node_modules le plus proche de prettier. Nous supposions qu'il y aurait toujours un répertoire prettier,
ce qui provoquait un plantage si le nom était différent.
Nous avons modifié la logique de recherche dans Prettier 1.14 : vous pouvez désormais renommer le répertoire prettier si nécessaire
(par exemple pour publier un fork sur npm).
Prise en charge de filepath dans le navigateur (#4721 par @ikatyang)
Dans Prettier 1.13, nous avions ajouté le support natif pour exécuter Prettier dans le navigateur, mais le seul moyen de
choisir le parser était via l'option parser. Prettier 1.14 ajoute le support de l'option filepath dans l'API navigateur,
permettant à Prettier d'inférer le parser à utiliser, comme avec l'API Node.js.
Cela sera particulièrement utile pour les applications d'éditeurs web !
Exposition de isPreviousLineEmpty aux plugins (#4748 par @warrenseine)
Précédemment, nous exposions isNextLineEmpty aux plugins mais pas isPreviousLineEmpty.
Prettier 1.14 l'expose désormais, car cela peut être utile dans certains scénarios comme les directives en C#.
JavaScript
Prise en charge des littéraux BigInt (#4697 par @ikatyang)
Les littéraux BigInt sont désormais pris en charge dans le parser babylon par défaut.
const bigInt = 1n;
Prise en charge des expressions throw (#4695 par @VojtechStep)
Les expressions throw sont désormais prises en charge dans le parser babylon par défaut.
const assert = x => x || throw new Error('...');
Toujours développer le premier argument si le second est aussi une expression d'appel (#4657 par @duailibe)
Précédemment, nous avions un cas spécial pour ne pas casser les appels de fonction
s'il n'y avait que 2 paramètres et que le premier était une fonction.
Cela fonctionnait bien, mais si le second paramètre était aussi une fonction, le résultat n'était pas optimal.
// 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}`)
);
Ajout de parenthèses pour await dans les liaisons (#4778 par @ikatyang)
Précédemment, Prettier supprimait incorrectement les parenthèses nécessaires pour await dans la syntaxe expérimentale de liaison,
altérant sa signification. Prettier 1.14 préserve désormais correctement les parenthèses.
// 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();
};
Autoriser super et await au niveau racine (#4823 par @ikatyang)
super et await ne sont normalement autorisés que dans les classes et fonctions async,
mais notre option formatage partiel ne fonctionnait pas correctement lors de la sélection de contenu de fonction.
Prettier 1.14 les autorise désormais partout.
super();
await doSomething();
Exclusion de this et super dans les heuristiques de composition fonctionnelle (#4836 par @princed)
Dans Prettier 1.13, nous avions amélioré le formatage des fonctions de composition fonctionnelle (par exemple pipe, compose, etc.)
en plaçant leurs paramètres sur des lignes séparées, mais cela entraînait des faux positifs pour les fonctions portant le même nom dans les classes.
Prettier 1.14 exclut désormais this et super des heuristiques de composition fonctionnelle.
// 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
Prise en charge de import.meta (#4762 par @ikatyang)
Dans Prettier 1.13, la version du parseur TypeScript que nous utilisions ne prenait pas en charge la syntaxe import.meta.
Nous avons mis à jour notre parseur TypeScript dans Prettier 1.14 pour qu'il soit désormais analysé et formaté correctement.
console.log(import.meta.url);
Propriété optionnelle avec clé StringLiteral dans une classe (#4762 par @ikatyang)
Dans la version précédente, le ? des propriétés optionnelles utilisant un littéral de chaîne comme clé était incorrectement supprimé.
Nous avons corrigé ce bogue dans Prettier 1.14 pour qu'il soit conservé.
// 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;
}
Générer une erreur sur les super-classes multiples (#4762 par @ikatyang)
Les classes ne peuvent avoir qu'une seule classe parente,
mais l'AST TypeScript autorise les super-classes multiples car la clause extends
a la même structure interne que la clause implements.
Auparavant, les super-classes supplémentaires étaient silencieusement ignorées lors de l'impression,
ce qui pouvait causer de la confusion après le formatage.
Dans Prettier 1.14, elles sont désormais signalées comme des erreurs de syntaxe.
// 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.
*/
Prise en charge du spread enfant dans JSX (#4885 par @ikatyang)
Précédemment, les ... dans les spreads enfants des expressions JSX étaient incorrectement supprimés.
Nous avons corrigé ce problème dans Prettier 1.14.
// 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
Prise en charge de l'extension .js.flow (#4777 par @ikatyang)
L'extension .js.flow
est utilisée pour les fichiers de déclaration Flow, mais nous ne la reconnaissions pas auparavant.
Dans Prettier 1.14, ils devraient être détectés automatiquement,
vous évitant ainsi d'ajouter des configurations supplémentaires.
CSS/Less/SCSS
Gestion correcte des sauts de ligne entre front-matter et commentaires (#4701 par @evilebottnawi)
Les sauts de ligne multiples entre le front matter et un commentaire CSS étaient remplacés par un espace dans Prettier 1.13. Dans Prettier 1.14, nous insérons désormais un saut de ligne entre eux.
/* 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;
}
Prise en charge des at-rules se terminant par une accolade fermante (#4733 par @davidgomes)
Dans la version précédente, les at-rules se terminant par } n'étaient pas correctement analysées.
Prettier 1.14 les reconnaît et les formate désormais correctement.
/* Input */
@mixin placeholder {
&::placeholder {@content}
}
/* Output (Prettier 1.13) */
/*
SyntaxError: CssSyntaxError Unclosed block
*/
/* Output (Prettier 1.14) */
@mixin placeholder {
&::placeholder {
@content;
}
}
Markdown
Préservation des autolinks d'email (#4740 par @ikatyang)
Les autolinks étaient formatés comme leur URL dans la version précédente, ce qui est acceptable.
Mais il existe un cas particulier pour les liens email qui sont résolus comme des liens mailto:.
Dans Prettier 1.14, les autolinks d'email sont préservés.
<!-- Input -->
<hello@example.com>
<!-- Output (Prettier 1.13) -->
<mailto:hello@example.com>
<!-- Output (Prettier 1.14) -->
<hello@example.com>
Ne pas exiger d'espace après le nom de langage dans les blocs Markdown (#4783 par @kachkaev)
Dans Prettier 1.12, nous avions ajouté la prise en charge des attributs après le langage dans les blocs de code, ce qui nécessitait qu'ils soient séparés par des espaces. Mais cela introduisait une incohérence avec la coloration syntaxique dans Atom où les blocs de code étaient colorés sans être formatés. Nous avons mis à jour notre logique de détection dans Prettier 1.14 pour un comportement cohérent.
<!-- 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;
```
Utiliser les alias de langage pour trouver le parseur des blocs de code Markdown (#4734 par @ikatyang)
Auparavant, nous utilisions le name et les extensions du langage pour déterminer quel parser utiliser pour le formatage des blocs de code.
Nous avons constaté qu'il était impossible de formater des blocs de code JSON with Comments tout en conservant le surlignage syntaxique,
car ils partagent la même extension .json que le JSON standard, alors que la coloration syntaxique des commentaires n'est disponible qu'en JSON5.
Prettier 1.14 ajoute la prise en charge des aliases de langage pour identifier le parser,
vous permettant ainsi d'utiliser jsonc pour formater et déclencher le surlignage syntaxique des blocs de code JSON with Comments.
<!-- Input -->
```jsonc
// comment
{"a":1}
```
<!-- Output (Prettier 1.13) -->
```jsonc
// comment
{"a":1}
```
<!-- Output (Prettier 1.14) -->
```jsonc
// comment
{ "a": 1 }
```
Préserver les entités pour les caractères encodés dont le point de code dépasse U+FFFF (#4832 par @ikatyang)
Le parser Markdown utilisé (remark) convertit chaque caractère encodé en un nœud AST unique,
nous permettant de restaurer le caractère encodé en vérifiant si la valeur du nœud AST a une longueur de 1.
Cependant, une exception existe : un caractère unique peut avoir une longueur de 2 si son point de code dépasse 0xFFFF,
car JavaScript utilise l'encodage UTF-16 (2 octets).
Prettier 1.14 reconnaît correctement ces caractères, évitant ainsi leur transformation en caractère littéral.
<!-- Input -->
😉
<!-- Output (Prettier 1.13) -->
😉
<!-- Output (Prettier 1.14) -->
😉
Vue
Prise en charge du formatage par plage pour les fichiers Vue (#4868 par @ikatyang)
Auparavant, le formatage par plage n'était pas disponible pour Vue,
mais Prettier 1.14 ajoute cette fonctionnalité.
GraphQL
Préserver les sauts de ligne dans les valeurs de chaîne non-bloc (#4808 par @ikatyang)
Les valeurs de chaîne non-bloc ne peuvent occuper qu'une seule ligne,
mais Prettier 1.13 transformait incorrectement les \n échappés en véritables sauts de ligne.
Prettier 1.14 imprime désormais correctement \n.
# 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
}
}
