Prettier 1.15 : Prise en charge du HTML, Vue, Angular et MDX

7 novembre 2018 · 32 minutes de lecture

Traduction Bêta Non Officielle

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 HTML, Vue, Angular et MDX. Elle respecte également la position des décorateurs, ajoute une option pour les guillemets simples en JSX, permet l'inférence de parser via le shebang, ajoute la prise en charge de plusieurs nouvelles fonctionnalités syntaxiques et inclut quelques ajustements de formatage.

Principales fonctionnalités

HTML/Vue/Angular

Prise en charge de HTML, Vue et Angular (#5259 par @ikatyang, #4753 par @evilebottnawi, #2083 par @azz)

Prettier peut désormais formater les fichiers HTML, Vue et Angular ! 🎉

Nous utilisons angular-html-parser, un parseur HTML extrait d'Angular, pour analyser ces fichiers HTML et templates HTML. Il devrait être hautement conforme à la spécification HTML grâce à l'équipe Angular.

Quelques points marquants :

Formatage sensible aux espaces blancs

Comme vous pouvez le constater dans vos travaux HTML quotidiens, les deux cas suivants ne produisent pas le même résultat :

	html	output
with spaces	`1<b> 2 </b>3`	1 2 3
without spaces	`1<b>2</b>3`	123

Cela se produit car les espaces blancs sont significatifs dans les éléments en ligne.

Pour cette raison, nous ne pouvons pas formater en toute sécurité

<a href="https://prettier.io/">Prettier is an opinionated code formatter.</a>

<a href="https://prettier.io/">
  Prettier is an opinionated code formatter.
</a>

car cela pourrait modifier le rendu dans le navigateur.

Plutôt que de casser votre code ou ne rien faire, nous introduisons le formatage sensible aux espaces blancs qui :

suit la valeur par défaut de la propriété CSS display pour chaque élément afin d'identifier si les espaces blancs à l'intérieur sont significatifs,
et organise les balises de manière à éviter d'ajouter ou de supprimer des espaces blancs significatifs.

Par exemple :

<!-- <span> is an inline element, <div> is a block element -->

<!-- input -->
<span class="dolorum atque aspernatur">Est molestiae sunt facilis qui rem.</span>
<div class="voluptatem architecto at">Architecto rerum architecto incidunt sint.</div>

<!-- output -->
<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>
<div class="voluptatem architecto at">
  Architecto rerum architecto incidunt sint.
</div>

Nous autorisons également les commentaires magiques (ex: ) pour indiquer à Prettier comment formater les éléments, étant donné que l'affichage CSS peut être modifié :

<!-- input -->
<!-- display: block -->
<span class="dolorum atque aspernatur">Est molestiae sunt facilis qui rem.</span>

<!-- output -->
<!-- display: block -->
<span class="dolorum atque aspernatur">
  Est molestiae sunt facilis qui rem.
</span>

Il existe également une option globale pour la sensibilité aux espaces blancs, au cas où vous voudriez une sécurité maximale ou si les espaces blancs ne vous importent pas :

--html-whitespace-sensitivity (par défaut css)

css - Respecte la valeur par défaut de la propriété CSS display.
strict - Tous les espaces blancs sont considérés comme significatifs.
ignore - Tous les espaces blancs sont considérés comme non significatifs.

Inférence automatique du parser

Prettier utilise le nom de fichier pour déduire quel parser utiliser. Voici les modèles par défaut pour HTML, Vue et Angular :

*.html: --parser html
*.component.html: --parser angular
*.vue: --parser vue

Assurez-vous que votre nom de fichier correspond au parser correct (surtout pour les utilisateurs d'Angular) ; dans le cas contraire, vous devrez spécifier manuellement le parser à utiliser via le champ overrides.

Notez que le formatage spécifique aux frameworks ne sera pas déclenché avec --parser html.

Littéraux de modèle HTML en JavaScript

Cette version ajoute également la prise en charge du tag de template html (ou d'un commentaire "tag" contenant HTML) :

html`code`
/* HTML */ `code`

// input
const foo = html`<div class="voluptatem architecto at">Architecto rerum ${interpolation} architecto incidunt sint.</div>`;

// output
const foo = html`
  <div class="voluptatem architecto at">
    Architecto rerum ${interpolation} architecto incidunt sint.
  </div>
`;

Formatage Vue

Les structures syntaxiques spécifiques suivantes à Vue sont prises en charge :

interpolation
- {{ something }}
attribut
- v-something
- :something
- @something
- v-for
- slot-scope

Formatage Angular

Les structures syntaxiques spécifiques à Angular suivantes sont prises en charge :

interpolation
- {{ something }}
attribut
- (something)
- [something]
- [(something)]
- *something
template inline
- @Component({ template: `<div>Hello World</div>` })

MDX

Support de MDX (#4975 par @ikatyang)

MDX est une extension Markdown permettant d'utiliser JSX pour créer de la documentation. Vous pouvez désormais utiliser Prettier pour le formater, et nous formaterons à la fois les parties Markdown et JS pour vous !

<!-- Input -->

import {
  colors } from
   './theme'
import     Palette from     './components/palette'

#      Colors

<Palette colors={
      colors}
  />

<!-- Output -->

import { colors } from "./theme";
import Palette from "./components/palette";

# Colors

<Palette colors={colors} />

JavaScript

Aplatissement des branches else pour les ternaires imbriqués (#5039 par @suchipi, #5272 par @duailibe, #5333 par @ikatyang)

Auparavant, les ternaires imbriqués étaient toujours indentés, ce qui créait des niveaux d'indentation croissants pour les ternaires profondément imbriqués. Pour résoudre ce problème, nous avons aplati la branche else des ternaires imbriqués, de manière similaire au formatage des blocs if..else if..else.

// Input
const example1 =
    someValue === 'a' ? 'hello world, branch a'
  : someValue === 'b' ? 'hello world, branch a && b'
  : someValue === 'c' ? 'hello world, branch a && b && c'
  : someValue === 'd' ? 'hello world, branch a && b && c && d'
  : null;

const example2 =
  someValue === 'a'
    ? someValue === 'b'
      ? someValue === 'c'
        ? 'hello world, branch a && b && c'
        : 'hello world, branch a && b && !c'
      : 'hello world, branch a && !b'
    : null;

// Output (Prettier 1.14)
const example1 =
  someValue === "a"
    ? "hello world, branch a"
    : someValue === "b"
      ? "hello world, branch a && b"
      : someValue === "c"
        ? "hello world, branch a && b && c"
        : someValue === "d"
          ? "hello world, branch a && b && c && d"
          : null;

const example2 =
  someValue === "a"
    ? someValue === "b"
      ? someValue === "c"
        ? "hello world, branch a && b && c"
        : "hello world, branch a && b && !c"
      : "hello world, branch a && !b"
    : null;

// Output (Prettier 1.15)
const example1 =
  someValue === "a"
    ? "hello world, branch a"
    : someValue === "b"
    ? "hello world, branch a && b"
    : someValue === "c"
    ? "hello world, branch a && b && c"
    : someValue === "d"
    ? "hello world, branch a && b && c && d"
    : null;

const example2 =
  someValue === "a"
    ? someValue === "b"
      ? someValue === "c"
        ? "hello world, branch a && b && c"
        : "hello world, branch a && b && !c"
      : "hello world, branch a && !b"
    : null;

Conservation des décorateurs inline s'ils étaient écrits ainsi (#5188 par @duailibe)

Avant Prettier 1.14, nous placions toujours les décorateurs sur la même ligne que l'élément décoré.

Nous avons reçu des retours d'utilisateurs indiquant que ce formatage n'était pas idéal. Après réflexion, nous l'avons modifié dans Prettier 1.14 : les décorateurs étaient alors toujours placés sur une ligne distincte de l'élément décoré.

Cependant, d'autres utilisateurs nous ont fait part que ce formatage n'était pas toujours idéal.

Nous souhaitons maintenir un formatage cohérent dans Prettier lorsque possible. Nous avons donc cherché une heuristique pour décider quand placer les décorateurs sur la même ligne ou sur une ligne séparée.

Après une longue discussion dans #4924, nous avons conclu qu'il n'existait pas de méthode fiable pour déterminer ce qui devrait être inline ou non. Dans Prettier 1.15, nous avons donc décidé de respecter le style d'origine écrit par l'utilisateur : si un saut de ligne était présent entre le décorateur et l'élément décoré, nous le conservons ; sinon, nous ne l'ajoutons pas.

// Input
class Hello {
  @decorator inline = 'value';

  @decorator
  ownLine = 'value';

  @decorator({
    hello: 'world'
  }) multiLine = 'value';
}

// Output (Prettier 1.14)
class Hello {
  @decorator
  inline = "value";

  @decorator
  ownLine = "value";

  @decorator({
    hello: "world"
  })
  multiLine = "value";
}

// Output (Prettier 1.15)
class Hello {
  @decorator inline = "value";

  @decorator
  ownLine = "value";

  @decorator({
    hello: "world"
  })
  multiLine = "value";
}

Respect de l'ordre original des décorateurs (#5207 par @duailibe)

Les décorateurs ne font toujours pas partie du standard ECMA officiel, et la position des décorateurs sur les classes exportées reste une question non tranchée. Pour aider les auteurs de propositions à recueillir des retours, Babel 7 a ajouté le support des décorateurs avant et après les classes exportées. Prettier 1.15 prend en charge ces deux positions et respecte l'emplacement que vous avez choisi pour le(s) décorateur(s). (Une fois la spécification standardisée, nous adopterons un formatage cohérent sans tenir compte de la saisie utilisateur.)

// decorator before export
@decorator export class Bar {}

// decorator after export
export @decorator class Foo {}

Amélioration de l'heuristique de rupture d'objets (#5205 par @j-f1)

Auparavant, Prettier divisait automatiquement les objets sur plusieurs lignes s'ils dépassaient la largeur d'impression. Il conservait également les objets sur plusieurs lignes si un saut de ligne était présent dans le code source. Cela rendait difficile le regroupement d'un objet puisqu'il fallait le fusionner manuellement sur une seule ligne. Comme les modifications de formatage manuel vont à l'encontre de l'objectif de Prettier, nous avons modifié ce comportement : la décision de rupture se base désormais uniquement sur la présence d'un saut de ligne entre le { et la première clé :

// Input
const data = {  foo: 'bar',
  baz: 'quux'
}
/* You’d get this format by deleting the newline after the `{` */

// Output (Prettier 1.14)
const data = {
  foo: 'bar',
  baz: 'quux'
}

// Output (Prettier 1.15)
const data = { foo: 'bar', baz: 'quux' }

JSX

Option pour utiliser des guillemets simples en JSX (#4798 par @smirea)

Après une forte demande de la communauté, Prettier 1.15 ajoute une option pour imprimer des guillemets simples en JSX : --jsx-single-quote (ou jsxSingleQuote dans la config/API).

// with --jsx-single-quote
<div class='hello'>world</div>

// without --jsx-single-quote
<div class="hello">world</div>

Fractionnement correct du texte JSX (#5006 par @yuliaHope)

Prettier 1.14 avait accidentellement introduit des sauts de ligne problématiques en JSX. Ces cas sont désormais corrigés.

// Input
<div>
  Sales tax estimated using a rate of {salesTax * 100}%.
</div>;
<BasicText light>(avg. {value}/5)</BasicText>;
<Link to={orgURL(this.props.org.name)}>
  Go to {this.props.org.name}'s profile
</Link>;

// Output (Prettier 1.14)
<div>
  Sales tax estimated using a rate of {salesTax * 100}
  %.
</div>;
<BasicText light>
  (avg. {value}
  /5)
</BasicText>;
<Link to={orgURL(this.props.org.name)}>
  Go to {this.props.org.name}
  's profile
</Link>;

// Output (Prettier 1.15)
<div>Sales tax estimated using a rate of {salesTax * 100}%.</div>;
<BasicText light>(avg. {value}/5)</BasicText>;
<Link to={orgURL(this.props.org.name)}>
  Go to {this.props.org.name}'s profile
</Link>;

Flow

Prise en charge de inexact (#5304 par @jbrown215, #5356 par @existentialism)

L'équipe Flow prévoit de traiter tous les types d'objets comme exacts par défaut à l'avenir, d'où l'introduction d'une nouvelle syntaxe pour indiquer les types d'objets inexacts. Cette syntaxe est désormais prise en charge dans Prettier 1.15.

type T = {
  a: number,
  ...
}

Ne pas altérer les commentaires de transtypage Flow (#5280, #5290 par @swac)

Précédemment, les parenthèses entourant les commentaires de transtypage Flow étaient parfois supprimées, ce qui cassait la syntaxe des commentaires Flow. Ce problème est résolu dans Prettier 1.15.

// Input
(obj /*: Class */).property

// Output (Prettier 1.14)
obj /*: Class */.property;

// Output (Prettier 1.15)
(obj /*: Class */).property;

Markdown

Préservation de la syntaxe mathématique (#5050, #5220 par @ikatyang)

Précédemment, certaines structures syntaxiques de remark-math étaient altérées car traitées comme du texte normal. Elles sont désormais préservées dans Prettier 1.15 pour une utilisation sécurisée de la syntaxe mathématique.

$inline-math$

$$
block-math
$$

Autres changements

API/CLI

Inférence du parser via shebang sans extension de fichier (#5149 par @haggholm)

Précédemment, l'inférence du parser reposait sur l'extension de fichier, mais les scripts CLI n'ont souvent pas d'extension, nécessitant une spécification manuelle peu pratique. Dans Prettier 1.15, lors du formatage d'un fichier sans extension, la première ligne est analysée : si un shebang est présent, il sert à inférer le parser approprié.

# Input

$ cat bin/example

#!/usr/bin/env node

  require ( "../src/cli" ) . run ( )
$ prettier bin/example
# Output (Prettier 1.14)

[error] No parser could be inferred for file: bin/example

# Output (Prettier 1.15) #!/usr/bin/env node require("../src/cli").run();

Ajout de la commande `trim` pour supprimer les espaces en début de ligne (#4772 par @warrenseine)

Précédemment dans l'API de plugin, aucune méthode ne permettait de supprimer l'indentation de la ligne courante. Bien que des solutions alternatives existaient, aucune n'était totalement fiable, d'où l'introduction de la nouvelle commande trim pour un retrait fiable des espaces.

Messages de validation colorés (#5020, #5057 par @ikatyang)

Précédemment, les messages d'erreur de validation d'options manquaient de couleur, rendant difficile l'identification des options invalides et des valeurs acceptables. Dans Prettier 1.15, la compréhension est immédiate grâce au code couleur.

# Input

$ prettier filename.js --trailing-comma wow
# Output (Prettier 1.14)

[error] Invalid ``--trailing-comma`` value. Expected "all", "es5" or "none", but received `"wow"`.

# Output (Prettier 1.15) [error] Invalid --trailing-comma value. Expected "all", "es5" or "none", but received "wow".

Permettre à l'imprimeur de prétraiter l'AST (#5041 par @ikatyang)

Parfois, nous devons transformer l'AST pour faciliter son impression. Auparavant, cela était fait dans l'analyseur syntaxique (parser), mais cette méthode exposait également les détails internes aux utilisateurs externes, qui pouvaient avoir tenté de construire un analyseur personnalisé, ce qui n'est pas idéal. Dans Prettier 1.15, vous pouvez désormais utiliser printer.preprocess pour prétraiter l'AST sans exposer les détails internes de l'API.

interface Printer {
  preprocess(ast: AST, options: object): AST;
}

Meilleur message d'erreur pour les formats de configuration non pris en charge (#4969 par @ikatyang)

Auparavant, le chargement d'un fichier de configuration dans un format non pris en charge générait un message d'erreur qui ressemblait à un bug dans Prettier. Nous avons donc amélioré le message dans Prettier 1.15.

# Input

$ prettier filename.js --config .prettierrc.wow
# Output (Prettier 1.14)

[error] Invalid configuration file: Cannot read property 'sync' of undefined

# Output (Prettier 1.15) [error] Invalid configuration file: No sync loader specified for extension ".wow"

Ajout d'une option pour forcer les fins de ligne (#5327 par @kachkaev)

Auparavant, Prettier respectait toujours vos fins de ligne originales, ce qui convient dans la plupart des cas. Mais lorsque des personnes collaborent sur un projet à partir de différents systèmes d'exploitation, il devient facile de se retrouver avec des fins de ligne mélangées dans le dépôt git central, ce qui génère de grandes différences (diffs). Prettier 1.15 ajoute une option --end-of-line <auto|lf|crlf|cr> pour vous aider à gérer ces problèmes de fins de ligne.

JavaScript

Traiter les commentaires à une seule étoile comme du JSDoc (#5206 par @j-f1, #5330 par @lydell)

Prettier va désormais correctement indenter les commentaires de style JSDoc avec une seule * sur la première ligne (/* vs /**) lorsque l'indentation du commentaire change :

// Input
if (true) {
    /*
     * Oh no
     */
}

// Output (Prettier 1.14)
if (true) {
  /*
   	 * Oh no
 	   */
}

// Output (Prettier 1.15)
if (true) {
  /*
 	 * Oh no
 	 */
}

Parenthèses correctes pour les mélanges exponentiation/modulo (#5243 par @bakkot)

Auparavant, les parenthèses pour les mélanges exponentiation/modulo étaient supprimées par erreur, mais nous avons corrigé cela dans Prettier 1.15.

// Input
const val = (n % 10) ** 2

// Output (Prettier 1.14)
const val = n % 10 ** 2;

// Output (Prettier 1.15)
const val = (n % 10) ** 2;

Impression correcte des commentaires dans `try..finally` (#5252 par @aquibm)

Dans les versions précédentes, certains commentaires dans une instruction try-finally étaient imprimés dans le mauvais ordre. Prettier les imprime désormais correctement.

// Input
// comment 1
try {
    // comment 2
}
// comment 3
finally // comment 4
{
    // comment 5
}

// Output (Prettier 1.14)
// comment 1
try {
  // comment 2
} finally { // comment 4
  // comment 3
  // comment 5
}

// Output (Prettier 1.15)
// comment 1
try {
  // comment 2
} finally {
  // comment 3
  // comment 4
  // comment 5
}

Impression des commentaires dans la clause catch au bon endroit (#5202 par @duailibe)

Les commentaires dans les clauses catch sont désormais imprimés sur leur propre ligne, comme pour les autres clauses.

// Input
try {} catch (
  // comment
  e
) {}

// Output (Prettier 1.14)
try {
} catch (// comment
e) {}

// Output (Prettier 1.15)
try {
} catch (
  // comment
  e
) {}

Inline l'argument s'il s'agit d'une fonction fléchée avec une expression conditionnelle comme corps (#5209 par @duailibe)

Il n'est pas nécessaire d'ajouter un niveau d'indentation supplémentaire pour un argument d'appel de fonction qui est une fonction fléchée avec une expression conditionnelle comme corps. Nous les mettons désormais en ligne dans Prettier 1.15.

// Input
x.then(() => a ?
  veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong:
  veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
);

// Output (Prettier 1.14)
x.then(
  () =>
    a
      ? veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
      : veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
);

// Output (Prettier 1.15)
x.then(() =>
  a
    ? veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
    : veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
);

Correction de l'indentation inattendue dans le déclarateur de variable causée par des commentaires (#5190 par @duailibe)

Dans les versions précédentes, les commentaires dans les déclarations de variables provoquaient l'impression des déclarateurs de variable sans indentation, mais cela a été corrigé dans Prettier 1.15.

// Input
const // Comment
	a = 1;

// Output (Prettier 1.14)
const // Comment
a = 1;

// Output (Prettier 1.15)
const // Comment
  a = 1;

Ne pas supprimer les parenthèses pour les ternaires dans les expressions de membre optionnelles (#5179 par @existentialism)

Prettier 1.14 supprimait incorrectement les parenthèses autour des opérateurs ternaires lorsqu'ils apparaissaient dans des expressions de membre optionnelles (?.). Ces cas sont désormais correctement imprimés dans Prettier 1.15.

// Input
(a ? b : c)?.d;

// Output (Prettier 1.14)
a ? b : c?.d;

// Output (Prettier 1.15)
(a ? b : c)?.d;

Échapper `${` ainsi que les backticks dans les tags GraphQL (#5137 par @lydell)

Auparavant, les chaînes de type interpolation étaient incorrectement déséchappées dans du GraphQL embarqué, ce qui amenait JavaScript à les traiter comme une interpolation. Elles sont correctement échappées dans Prettier 1.15.

// Input
const schema = gql`
type Project {
    "Pattern: \`\${project}\`"
    pattern: String
}
`;

// Output (Prettier 1.14)
const schema = gql`
  type Project {
    "Pattern: \`${project}\`"
    pattern: String
  }
`;

// Output (Prettier 1.15)
const schema = gql`
  type Project {
    "Pattern: \`\${project}\`"
    pattern: String
  }
`;

Ne pas supprimer les guillemets dans les clés si elles ne sont pas compatibles ES5 (#5157 par @koba04)

Auparavant, Prettier supprimait les guillemets dans les clés si elles n'étaient pas nécessaires en ES2015, ce qui rendait la sortie incompatible avec ES5. Prettier 1.15 ne les supprime que si elles ne sont pas nécessaires en ES5.

// Input
var obj = {
  "𐊧": 'ok',
  𐊧: 'ok'
};

// Output (Prettier 1.14)
var obj = {
  𐊧: "ok",
  𐊧: "ok"
};

// Output (Prettier 1.15)
var obj = {
 "𐊧": "ok",
  𐊧: "ok"
};

Ne pas regrouper les arguments si le deuxième argument d'une fonction est un ternaire (#5151 par @onurtemizkan)

Nous avions des cas particuliers qui regroupaient (hug) les arguments d'appel de fonction si le premier est une fonction et que le second n'est pas une expression complexe, mais nous considérions les ternaires comme des expressions non complexes. Or ils peuvent être complexes, nous avons donc modifié ce comportement dans Prettier 1.15.

// Input
func(
  () => { thing(); },
  something(longArgumentName, anotherLongArgumentName) ? someOtherThing() : somethingElse(true, 0)
);

// Output (Prettier 1.14)
func(() => {
  thing();
}, something(longArgumentName, anotherLongArgumentName) ? someOtherThing() : somethingElse(true, 0));

// Output (Prettier 1.15)
func(
  () => {
    thing();
  },
  something(longArgumentName, anotherLongArgumentName)
    ? someOtherThing()
    : somethingElse(true, 0)
);

Ajouter la prise en charge des timeouts passés comme nombres dans les fonctions de test (#5085 par @j-f1)

Ceci préserve le formatage spécial de Prettier pour les fonctions de test lorsqu'un timeout (nombre) est passé en troisième paramètre :

// Input
it('Handles at least 10k untracked files without failing', async () => {
  hello()
}, 25000)

// Output (Prettier 1.14)
it(
  "Handles at least 10k untracked files without failing",
  async () => {
    hello();
  },
  25000
);

// Output (Prettier 1.15)
it('Handles at least 10k untracked files without failing', async () => {
  hello()
}, 25000)

Formater les appels de type beforeEach comme des appels de fonction normaux (#5011 par @ericsakmar)

Précédemment, les arguments dans beforeEach étaient regroupés incorrectement. Nous avons corrigé ce problème dans Prettier 1.15.

// Input
beforeEach(done =>
  startService()
    .pipe(tap(service => (instance = service)))
    .subscribe(() => done()),
);

// Output (Prettier 1.14)
beforeEach(done =>
  startService()
    .pipe(tap(service => (instance = service)))
    .subscribe(() => done()));

// Output (Prettier 1.15)
beforeEach(done =>
  startService()
    .pipe(tap(service => (instance = service)))
    .subscribe(() => done())
);

Imprimer le commentaire précédant l'opérateur pipeline sur sa propre ligne (#5015 par @flxwu)

Dans Prettier 1.14, un commentaire devant un opérateur pipeline empêchait l'indentation de l'argument droit. Ce problème est résolu dans Prettier 1.15.

// Input
function pipeline() {
	0
	// Comment
	|> x
}

// Output (Prettier 1.14)
function pipeline() {
  0
    |> // Comment
    x;
}

// Output (Prettier 1.15)
function pipeline() {
  0 |>
    // Comment
    x;
}

Préserver les commentaires isolés dans les expressions `new` (#5017 par @flxwu)

Passer un commentaire au lieu d'une expression à un appel new est désormais préservé au lieu d'être extrait des parenthèses.

// Input
new Thing(/* comment */)

// Output (Prettier 1.14)
new Thing /* comment */();

// Output (Prettier 1.15)
new Thing(/* comment */);

Supprimer la protection ASI redondante pour les expressions bind (#4970 par @TitanSnow)

Les points-virgules superflus pour les expressions bind sont supprimés avec --no-semi dans Prettier 1.15.

// Input
a::b.c

// Output (Prettier 1.14)
;a::b.c

// Output (Prettier 1.15)
a::b.c

Ne pas supprimer les parenthèses nécessaires dans les expressions bind (#4964 par @TitanSnow)

Les parenthèses nécessaires dans les expressions bind sont préservées dans Prettier 1.15.

// Input
a::(b.c());

// Output (Prettier 1.14)
a::b.c();

// Output (Prettier 1.15)
a::(b.c());

Corriger l'indentation des ternaires dans les appels de fonction (#4368 par @malcolmsgroves)

Les expressions logiques dans un ternaire situé dans un appel de fonction sont maintenant indentées correctement.

// Input
fn(
  bifornCringerMoshedPerplexSawder,
  askTrovenaBeenaDependsRowans,
  glimseGlyphsHazardNoopsTieTie === averredBathersBoxroomBuggyNurl &&
    anodyneCondosMalateOverateRetinol // <--
    ? annularCooeedSplicesWalksWayWay
    : kochabCooieGameOnOboleUnweave
);

// Output (Prettier 1.14)
fn(
  bifornCringerMoshedPerplexSawder,
  askTrovenaBeenaDependsRowans,
  glimseGlyphsHazardNoopsTieTie === averredBathersBoxroomBuggyNurl &&
  anodyneCondosMalateOverateRetinol // <--
    ? annularCooeedSplicesWalksWayWay
    : kochabCooieGameOnOboleUnweave
);

// Output (Prettier 1.15)
fn(
  bifornCringerMoshedPerplexSawder,
  askTrovenaBeenaDependsRowans,
  glimseGlyphsHazardNoopsTieTie === averredBathersBoxroomBuggyNurl &&
    anodyneCondosMalateOverateRetinol // <--
    ? annularCooeedSplicesWalksWayWay
    : kochabCooieGameOnOboleUnweave
);

Ne pas déplacer les commentaires dans les `import` (#5016 par @ericsakmar)

Les commentaires dans les import ne seront plus déplacés en sortie de l'import.

// Input
import x, {
  // comment
  y
} from 'z';


// Output (Prettier 1.14)
import x, { y } from "z";
// comment

// Output (Prettier 1.15)
import x, {
  // comment
  y
} from "z";

Corriger le commentaire instable dans `while` (#5251 par @jaideng123)

Les commentaires dans while sont maintenant formatés correctement pour qu'un formatage unique produise un résultat stable.

// Input
while(
    true
    // Comment
) {}

// First Output (Prettier 1.14)
while (true) // Comment
{}

// Second Output (Prettier 1.14)
while (
  true // Comment
) {}

// First & Second Output (Prettier 1.15)
while (
  true
  // Comment
) {}

Imprimer stablement les commentaires entre la déclaration de fonction et son corps (#5250 par @jaideng123)

Les commentaires entre une déclaration de fonction et son corps ne nécessitent plus deux formatages pour obtenir le résultat final.

// Input
function foo() // this is a function
{
  return 42
}

// First Output (Prettier 1.14)
function foo() { // this is a function
  return 42;
}

// Second Output (Prettier 1.14)
function foo() {
  // this is a function
  return 42;
}

// First & Second Output (Prettier 1.15)
function foo() {
  // this is a function
  return 42;
}

JSX

Ne pas casser les chaînes d'expressions logiques en JSX (#5092 par @duailibe)

Les indentations superflues pour les chaînes d'expressions logiques en JSX sont maintenant évitées.

// Input
const TestComponent = () => {
  return (
    <>
      {cats && memes && (
        <Foo bar><Trololol /></Foo>
      )}
    </>
  );
}

// Output (Prettier 1.14)
const TestComponent = () => {
  return (
    <>
      {cats &&
        memes && (
          <Foo bar>
            <Trololol />
          </Foo>
        )}
    </>
  );
};

// Output (Prettier 1.15)
const TestComponent = () => {
  return (
    <>
      {cats && memes && (
        <Foo bar>
          <Trololol />
        </Foo>
      )}
    </>
  );
};

Ne pas remplacer les espaces insécables par des espaces normaux (#5165 par @vjeux, #5334 par @ikatyang)

Précédemment, les espaces insécables étaient traités comme des espaces normaux, ce qui les remplaçait par des espaces réguliers. Ce problème est corrigé dans Prettier 1.15.

(· représente un espace insécable)

// Input
function OhMyWhitespace() {
  return (
    <Dialog>
      <p>
        Supprimer l’objectif «·{goal.name}·»·?
      </p>
    </Dialog>
  )
}

// Output (Prettier 1.14)
function OhMyWhitespace() {
  return (
    <Dialog>
      <p>
        Supprimer l’objectif «
        {goal.name}
        ·»·?
      </p>
    </Dialog>
  );
}

// Output (Prettier 1.15)
function OhMyWhitespace() {
  return (
    <Dialog>
      <p>Supprimer l’objectif «·{goal.name}·»·?</p>
    </Dialog>
  );
}

Ne pas casser les balises d'ouverture JSX simples (#5078 par @duailibe)

Les balises d'ouverture JSX simples ne sont plus cassées sur plusieurs lignes.

// Input
function HelloWorld() {
  const listItemText = (
    <ListItemText
      primary={
        <PrimaryText>{`Two Factor Authentication is ${enabledText}`}</PrimaryText>
      }
    />
  );
}

// Output (Prettier 1.14)
function HelloWorld() {
  const listItemText = (
    <ListItemText
      primary={
        <PrimaryText
        >{`Two Factor Authentication is ${enabledText}`}</PrimaryText>
      }
    />
  );
}

// Output (Prettier 1.15)
function HelloWorld() {
  const listItemText = (
    <ListItemText
      primary={
        <PrimaryText>{`Two Factor Authentication is ${enabledText}`}</PrimaryText>
      }
    />
  );
}

Corriger une régression pour les fonctions fléchées dans les expressions JSX (#5063 par @ikatyang)

// Input
<div className="search-filter-chips">
    {scopes.filter(scope => scope.value !== "").map((scope, i) => (
        <FilterChip
            query={this.props.query}
            onFilterChosen={this.onSearchScopeClicked}
        />
    ))}
</div>;

// Output (Prettier 1.14)
<div className="search-filter-chips">
  {scopes.filter(scope => scope.value !== "").map((scope, i) => (
    <FilterChip
      query={this.props.query}
      onFilterChosen={this.onSearchScopeClicked}
    />
  ))}
</div>;

// Output (Prettier 1.15)
<div className="search-filter-chips">
  {scopes
    .filter(scope => scope.value !== "")
    .map((scope, i) => (
      <FilterChip
        query={this.props.query}
        onFilterChosen={this.onSearchScopeClicked}
      />
    ))}
</div>;

Flow

Génériques en ligne avec un identifiant unique (#5066 par @duailibe)

Les génériques avec un seul identifiant sont désormais systématiquement mis en ligne.

// Input
const longVariableName: Array<number> = this.foo.bar.baz.collider.body.vertices.reduce();

// Output (Prettier 1.14)
const longVariableName: Array<
  number
> = this.foo.bar.baz.collider.body.vertices.reduce();

// Output (Prettier 1.15)
const longVariableName: Array<number> = this.foo.bar.baz.collider.body.vertices.reduce();

Ne pas toujours mettre en ligne les classes dans `extends` (#5244 par @aquibm)

Les classes dans extends sont désormais correctement réparties sur plusieurs lignes.

// Input
declare interface ExtendsMany extends Interface1, Interface2, Interface3, Interface4, Interface5, Interface6, Interface7 {
  x: string;
}

// Output (Prettier 1.14)
declare interface ExtendsMany
  extends Interface1, Interface2, Interface3, Interface4, Interface5, Interface6, Interface7 {
  x: string;
}

// Output (Prettier 1.15)
declare interface ExtendsMany
  extends Interface1,
    Interface2,
    Interface3,
    Interface4,
    Interface5,
    Interface6,
    Interface7 {
  x: string;
}

Ne pas ajouter de parenthèses inutiles pour les fonctions asynchrones dans `export default` (#5303 par @jbrown215)

Les parenthèses superflues autour de export default async function sont désormais supprimées. Cette erreur ne survenait qu'avec le parseur flow.

// Input
export default async function foo() {};

// Output (Prettier 1.14)
export default (async function foo() {});

// Output (Prettier 1.15)
export default async function foo() {}

TypeScript

Ajout d'une protection ASI pour les assertions non nulles (#5262 par @duailibe)

Les points-virgules nécessaires pour les assertions non nulles ne seront pas supprimés en mode --no-semi.

// Input
const el = ReactDOM.findDOMNode(ref)
;(el as HTMLElement)!.style.cursor = 'pointer'

// Output (Prettier 1.14)
const el = ReactDOM.findDOMNode(ref)
(el as HTMLElement)!.style.cursor = "pointer"

// Output (Prettier 1.15)
const el = ReactDOM.findDOMNode(ref)
;(el as HTMLElement)!.style.cursor = "pointer"

Ne pas ajouter de point-virgule supplémentaire pour les signatures de méthode avec `prettier-ignore` (#5160 par @onurtemizkan)

Le point-virgule supplémentaire pour les signatures de méthode est supprimé dans Prettier 1.15.

// Input
interface SharedWorkerGlobalScope extends WorkerGlobalScope {
    // prettier-ignore
    addEventListener(): void;
    addEventListener(type: string): void;
}

// Output (Prettier 1.14)
interface SharedWorkerGlobalScope extends WorkerGlobalScope {
  // prettier-ignore
  addEventListener(): void;;
  addEventListener(type: string): void;
}

// Output (Prettier 1.15)
interface SharedWorkerGlobalScope extends WorkerGlobalScope {
  // prettier-ignore
  addEventListener(): void;
  addEventListener(type: string): void;
}

Ne pas imprimer de parenthèses invalides pour la déstructuration avec valeur par défaut (#5096 par @ikatyang)

Précédemment, Prettier ajoutait des parenthèses invalides pour la déstructuration avec valeur par défaut. Ce problème est résolu dans Prettier 1.15.

// Input
({ prop: toAssign = "default" } = { prop: "propval" });

// Output (Prettier 1.14)
({ prop: (toAssign = "default") } = { prop: "propval" });

// Output (Prettier 1.15)
({ prop: toAssign = "default" } = { prop: "propval" });

Ne pas imprimer de point-virgule pour les propriétés de classe avec modificateurs en mode `--no-semi` (#5083 par @ikatyang)

Dans Prettier 1.14, des points-virgules étaient ajoutés en fin de propriété de classe lorsque la propriété suivante contenait des modificateurs, bien que ces points-virgules soient inutiles. Ces points-virgules superflus sont supprimés dans Prettier 1.15.

// Input
class Reader {
  private [kBuffer]: Buffer
  private [kOffset]: number
}

// Output (1.14)
class Reader {
  private [kBuffer]: Buffer;
  private [kOffset]: number
}

// Output (1.15)
class Reader {
  private [kBuffer]: Buffer
  private [kOffset]: number
}

Ne pas supprimer les parenthèses pour les nœuds complexes dans `extends` des ClassExpression (#5074 par @ikatyang)

Précédemment, les parenthèses pour les nœuds complexes dans extends des expressions de classe étaient supprimées par erreur, produisant du code invalide. Ce problème est résolu dans Prettier 1.15.

// Input
let Subclass2 = class extends (Superclass as AssertedSuperclass) {};

// Output (Prettier 1.14)
let Subclass2 = class extends Superclass as AssertedSuperclass {};

// Output (Prettier 1.15)
let Subclass2 = class extends (Superclass as AssertedSuperclass) {};

Ne pas supprimer les parenthèses nécessaires pour TSOptionalType (#5056 par @ikatyang)

Précédemment, les parenthèses nécessaires pour les types optionnels dans les tuples étaient supprimées par erreur, produisant du code invalide. Ce problème est résolu dans Prettier 1.15.

// Input
type T = [("a" | "b")?];

// Output (Prettier 1.14)
type T = ["a" | "b"?];

// Output (Prettier 1.15)
type T = [("a" | "b")?];

CSS

Ne pas imprimer de résultat incorrect en présence de front matter et `/* prettier-ignore */` (#5103 par @ikatyang)

Dans Prettier 1.14, les informations de position dans l'AST étaient décalées à cause de notre méthode d'extraction des front matters, ce qui entraînait une sortie invalide avec /* prettier-ignore */. Ce problème est résolu dans Prettier 1.15.

/* Input */
---
hello: world
---

/* prettier-ignore */
.foo {}

/* Output (Prettier 1.14) */
---
hello: world
---

/* prettier-ignore */
 pretti

/* Output (Prettier 1.15) */
---
hello: world
---

/* prettier-ignore */
.foo {}

Conserver les sauts de ligne dans les templates CSS-in-JS (#5240 par @onurtemizkan)

Les interpolations dans les templates CSS-in-JS pouvant être diverses, nous conservons désormais leurs sauts de ligne dans Prettier 1.15.

// Input
const foo = styled.div`
  ${secondary}
  flex: 0 0 auto;
`;

// Output (Prettier 1.14)
const foo = styled.div`
  ${secondary} flex: 0 0 auto;
`;

// Output (Prettier 1.15)
const foo = styled.div`
  ${secondary}
  flex: 0 0 auto;
`;

Markdown

Autoriser les espaces après les délimiteurs de front matters (#5107 par @ikatyang)

Précédemment, seuls les front matters sans espaces après leurs délimiteurs étaient détectés, ce qui provoquait une confusion avec les séparateurs thématiques (---). Nous avons résolu ce problème en autorisant les espaces après les délimiteurs dans Prettier 1.15, comme le fait GitHub pour le traitement des front matters.

(· représente un espace)

<!-- Input -->
---
Title: Title
---···

__strong__ **strong**

---

<!-- Output (Prettier 1.14) -->
---
Title: Title
---···
__strong__ **strong**
---

<!-- Output (Prettier 1.15) -->
---
Title: Title
---···

**strong** **strong**

---

Ne pas ajouter d'espaces entre les caractères latins et hangul (#5040 par @ikatyang)

Précédemment, nous insérions toujours un espace entre les caractères latins et CJK pour améliorer la lisibilité. Cependant, selon les retours reçus, le coréen utilise des espaces conventionnels, et l'ajout d'espaces supplémentaires causait des problèmes pour cette langue. Nous avons donc désactivé ce comportement pour le Hangul dans Prettier 1.15. Le comportement reste inchangé pour le chinois et le japonais.

<!-- Input -->
예문Latin예문Latin 예문Latin예문 Latin예문Latin 예문 Latin 예문

<!-- Output (Prettier 1.14) -->
예문 Latin 예문 Latin 예문 Latin 예문 Latin 예문 Latin 예문 Latin 예문

<!-- Output (Prettier 1.15) -->
예문Latin예문Latin 예문Latin예문 Latin예문Latin 예문 Latin 예문

Préserver les sauts de ligne initiaux et finaux dans les blocs de code encadrés (#5038 par @ikatyang)

Dans Prettier 1.14, les sauts de ligne initiaux et finaux étaient supprimés dans les blocs de code encadrés, ce qui empêchait d'autres plugins (ex: php) de formater correctement ces blocs. Prettier 1.15 préserve désormais ces sauts de ligne.

<!-- Input -->
```

hello

```

<!-- Output (Prettier 1.14) -->
```
hello
```

<!-- Output (Prettier 1.15) -->
```

hello

```

Formater en ligne les définitions de note de bas de page pour les paragraphes monolignes (#5025 par @ikatyang)

Auparavant, tout contenu excédant la largeur d'impression dans une note de bas de page était divisé sur plusieurs lignes. Cependant, diviser un paragraphe monoligne n'améliorait pas vraiment la lisibilité. Prettier 1.15 les formate donc systématiquement en une seule ligne.

<!-- Input -->
[^1]: In eos repellat fugit dolor veritatis doloremque nobis. Provident ut est illo.

<!-- Output (Prettier 1.14) -->
[^1]:

  In eos repellat fugit dolor veritatis doloremque nobis. Provident ut est illo.

<!-- Output (Prettier 1.15) -->
[^1]: In eos repellat fugit dolor veritatis doloremque nobis. Provident ut est illo.

Formater correctement les listes précédant des sauts de ligne vides (#5024 par @ikatyang)

Dans Prettier 1.14, les listes précédant des sauts de ligne vides étaient incorrectement interprétées comme des listes non compactes. Cela obligeait les utilisateurs à formater leur code deux fois pour obtenir un résultat stable, produisant parfois un rendu incorrect. Ce problème est corrigé dans Prettier 1.15.

// Input
if (condition) {
  md`
- 123
  - 456
`;
}

// First Output (Prettier 1.14)
if (condition) {
  md`
- 123
  - 456
  `;
}

// Second Output (Prettier 1.14)
if (condition) {
  md`
- 123

  - 456
  `;
}

// First & Second Output (Prettier 1.15)
if (true) {
  md`
- 123
  - 456
  `;
}

YAML

Échapper correctement les guillemets (#5236 par @ikatyang)

Précédemment, les chaînes contenant des guillemets échappés dans des doubles guillemets produisaient un rendu invalide. Prettier 1.15 les échappe désormais correctement.

# Input
"'a\"b"

# Output (Prettier 1.14)
''a"b'

# Output (Prettier 1.15)
'''a"b'

Préserver les commentaires finaux pour les documents et en-têtes (#5027 par @ikatyang)

Dans Prettier 1.14, certains commentaires finaux des documents et en-têtes pouvaient être déplacés. Prettier 1.15 les préserve systématiquement.

# Input
--- # hello
... # world

# Output (Prettier 1.14)
# hello
# world

# Output (Prettier 1.15)
--- # hello
... # world

Ne pas générer d'erreur pour les éléments de mappage avec valeurs longues (#5027 par @ikatyang)

Précédemment, les longues valeurs de mappage étaient incorrectement interprétées comme des clés, provoquant des erreurs syntaxiques car les clés implicites dépassant 1024 caractères sont interdites. Ce problème est résolu dans Prettier 1.15.

(long représente un texte dépassant 1024 caractères)

# Input
{x: long}

# Output (Prettier 1.14)
SyntaxError: The "undefine...ndefined" key is too long

# Output (Prettier 1.15)
{
  x: long
}

Préférer les clés implicites pour les valeurs de mappage vides (#4972 par @ikatyang)

Auparavant, un élément de mappage avec valeur vide utilisait systématiquement une clé explicite, ce qui n'est pas conventionnel et perturbait les utilisateurs. Prettier 1.15 utilise désormais toujours une clé implicite dans ces cas.

# Input
a:
  b:

# Output (Prettier 1.14)
a:
  ? b

# Output (Prettier 1.15)
a:
  b:

Merci ! ❤️

Un grand merci à tous les contributeurs de cette version, ainsi qu'aux personnes ayant remonté des problèmes et partagé leurs retours. Prettier est un projet communautaire qui ne peut exister que grâce à des personnes comme vous. Merci !

Remerciements particuliers à @j-f1, @suchipi et @existentialism pour leur relecture de cet article !

Principales fonctionnalités​

HTML/Vue/Angular​

Prise en charge de HTML, Vue et Angular (#5259 par @ikatyang, #4753 par @evilebottnawi, #2083 par @azz)​

Formatage sensible aux espaces blancs​

Inférence automatique du parser​

Littéraux de modèle HTML en JavaScript​

Formatage Vue​

Formatage Angular​

MDX​

Support de MDX (#4975 par @ikatyang)​

JavaScript​

Aplatissement des branches else pour les ternaires imbriqués (#5039 par @suchipi, #5272 par @duailibe, #5333 par @ikatyang)​

Conservation des décorateurs inline s'ils étaient écrits ainsi (#5188 par @duailibe)​

Respect de l'ordre original des décorateurs (#5207 par @duailibe)​

Amélioration de l'heuristique de rupture d'objets (#5205 par @j-f1)​

JSX​

Option pour utiliser des guillemets simples en JSX (#4798 par @smirea)​

Fractionnement correct du texte JSX (#5006 par @yuliaHope)​

Flow​

Prise en charge de inexact (#5304 par @jbrown215, #5356 par @existentialism)​

Ne pas altérer les commentaires de transtypage Flow (#5280, #5290 par @swac)​

Markdown​

Préservation de la syntaxe mathématique (#5050, #5220 par @ikatyang)​

Autres changements​

API/CLI​

Inférence du parser via shebang sans extension de fichier (#5149 par @haggholm)​

Ajout de la commande trim pour supprimer les espaces en début de ligne (#4772 par @warrenseine)​

Messages de validation colorés (#5020, #5057 par @ikatyang)​

Permettre à l'imprimeur de prétraiter l'AST (#5041 par @ikatyang)​

Meilleur message d'erreur pour les formats de configuration non pris en charge (#4969 par @ikatyang)​

Ajout d'une option pour forcer les fins de ligne (#5327 par @kachkaev)​

JavaScript​

Traiter les commentaires à une seule étoile comme du JSDoc (#5206 par @j-f1, #5330 par @lydell)​

Parenthèses correctes pour les mélanges exponentiation/modulo (#5243 par @bakkot)​

Impression correcte des commentaires dans try..finally (#5252 par @aquibm)​

Impression des commentaires dans la clause catch au bon endroit (#5202 par @duailibe)​

Inline l'argument s'il s'agit d'une fonction fléchée avec une expression conditionnelle comme corps (#5209 par @duailibe)​

Correction de l'indentation inattendue dans le déclarateur de variable causée par des commentaires (#5190 par @duailibe)​

Ne pas supprimer les parenthèses pour les ternaires dans les expressions de membre optionnelles (#5179 par @existentialism)​

Échapper ${ ainsi que les backticks dans les tags GraphQL (#5137 par @lydell)​

Ne pas supprimer les guillemets dans les clés si elles ne sont pas compatibles ES5 (#5157 par @koba04)​

Ne pas regrouper les arguments si le deuxième argument d'une fonction est un ternaire (#5151 par @onurtemizkan)​

Ajouter la prise en charge des timeouts passés comme nombres dans les fonctions de test (#5085 par @j-f1)​

Formater les appels de type beforeEach comme des appels de fonction normaux (#5011 par @ericsakmar)​

Imprimer le commentaire précédant l'opérateur pipeline sur sa propre ligne (#5015 par @flxwu)​

Préserver les commentaires isolés dans les expressions new (#5017 par @flxwu)​

Supprimer la protection ASI redondante pour les expressions bind (#4970 par @TitanSnow)​

Ne pas supprimer les parenthèses nécessaires dans les expressions bind (#4964 par @TitanSnow)​

Corriger l'indentation des ternaires dans les appels de fonction (#4368 par @malcolmsgroves)​

Ne pas déplacer les commentaires dans les import (#5016 par @ericsakmar)​

Corriger le commentaire instable dans while (#5251 par @jaideng123)​

Imprimer stablement les commentaires entre la déclaration de fonction et son corps (#5250 par @jaideng123)​

JSX​

Ne pas casser les chaînes d'expressions logiques en JSX (#5092 par @duailibe)​

Ne pas remplacer les espaces insécables par des espaces normaux (#5165 par @vjeux, #5334 par @ikatyang)​

Ne pas casser les balises d'ouverture JSX simples (#5078 par @duailibe)​

Corriger une régression pour les fonctions fléchées dans les expressions JSX (#5063 par @ikatyang)​

Flow​

Génériques en ligne avec un identifiant unique (#5066 par @duailibe)​

Ne pas toujours mettre en ligne les classes dans extends (#5244 par @aquibm)​

Ne pas ajouter de parenthèses inutiles pour les fonctions asynchrones dans export default (#5303 par @jbrown215)​

TypeScript​

Ajout d'une protection ASI pour les assertions non nulles (#5262 par @duailibe)​

Ne pas ajouter de point-virgule supplémentaire pour les signatures de méthode avec prettier-ignore (#5160 par @onurtemizkan)​

Ne pas imprimer de parenthèses invalides pour la déstructuration avec valeur par défaut (#5096 par @ikatyang)​

Ne pas imprimer de point-virgule pour les propriétés de classe avec modificateurs en mode --no-semi (#5083 par @ikatyang)​

Ne pas supprimer les parenthèses pour les nœuds complexes dans extends des ClassExpression (#5074 par @ikatyang)​

Ne pas supprimer les parenthèses nécessaires pour TSOptionalType (#5056 par @ikatyang)​

CSS​

Ne pas imprimer de résultat incorrect en présence de front matter et /* prettier-ignore */ (#5103 par @ikatyang)​

Conserver les sauts de ligne dans les templates CSS-in-JS (#5240 par @onurtemizkan)​

Markdown​

Autoriser les espaces après les délimiteurs de front matters (#5107 par @ikatyang)​

Ne pas ajouter d'espaces entre les caractères latins et hangul (#5040 par @ikatyang)​

Préserver les sauts de ligne initiaux et finaux dans les blocs de code encadrés (#5038 par @ikatyang)​

Formater en ligne les définitions de note de bas de page pour les paragraphes monolignes (#5025 par @ikatyang)​

Formater correctement les listes précédant des sauts de ligne vides (#5024 par @ikatyang)​

YAML​

Échapper correctement les guillemets (#5236 par @ikatyang)​

Préserver les commentaires finaux pour les documents et en-têtes (#5027 par @ikatyang)​

Principales fonctionnalités

HTML/Vue/Angular

Prise en charge de HTML, Vue et Angular (#5259 par @ikatyang, #4753 par @evilebottnawi, #2083 par @azz)

Formatage sensible aux espaces blancs

Inférence automatique du parser

Littéraux de modèle HTML en JavaScript

Formatage Vue

Formatage Angular

MDX

Support de MDX (#4975 par @ikatyang)

JavaScript

Aplatissement des branches else pour les ternaires imbriqués (#5039 par @suchipi, #5272 par @duailibe, #5333 par @ikatyang)

Conservation des décorateurs inline s'ils étaient écrits ainsi (#5188 par @duailibe)

Respect de l'ordre original des décorateurs (#5207 par @duailibe)

Amélioration de l'heuristique de rupture d'objets (#5205 par @j-f1)

JSX

Option pour utiliser des guillemets simples en JSX (#4798 par @smirea)

Fractionnement correct du texte JSX (#5006 par @yuliaHope)

Flow

Prise en charge de inexact (#5304 par @jbrown215, #5356 par @existentialism)

Ne pas altérer les commentaires de transtypage Flow (#5280, #5290 par @swac)

Markdown

Préservation de la syntaxe mathématique (#5050, #5220 par @ikatyang)

Autres changements

API/CLI

Inférence du parser via shebang sans extension de fichier (#5149 par @haggholm)

Ajout de la commande `trim` pour supprimer les espaces en début de ligne (#4772 par @warrenseine)

Messages de validation colorés (#5020, #5057 par @ikatyang)

Permettre à l'imprimeur de prétraiter l'AST (#5041 par @ikatyang)

Meilleur message d'erreur pour les formats de configuration non pris en charge (#4969 par @ikatyang)

Ajout d'une option pour forcer les fins de ligne (#5327 par @kachkaev)

JavaScript

Traiter les commentaires à une seule étoile comme du JSDoc (#5206 par @j-f1, #5330 par @lydell)

Parenthèses correctes pour les mélanges exponentiation/modulo (#5243 par @bakkot)

Impression correcte des commentaires dans `try..finally` (#5252 par @aquibm)

Impression des commentaires dans la clause catch au bon endroit (#5202 par @duailibe)

Inline l'argument s'il s'agit d'une fonction fléchée avec une expression conditionnelle comme corps (#5209 par @duailibe)

Correction de l'indentation inattendue dans le déclarateur de variable causée par des commentaires (#5190 par @duailibe)

Ne pas supprimer les parenthèses pour les ternaires dans les expressions de membre optionnelles (#5179 par @existentialism)

Échapper `${` ainsi que les backticks dans les tags GraphQL (#5137 par @lydell)

Ne pas supprimer les guillemets dans les clés si elles ne sont pas compatibles ES5 (#5157 par @koba04)

Ne pas regrouper les arguments si le deuxième argument d'une fonction est un ternaire (#5151 par @onurtemizkan)

Ajouter la prise en charge des timeouts passés comme nombres dans les fonctions de test (#5085 par @j-f1)

Formater les appels de type beforeEach comme des appels de fonction normaux (#5011 par @ericsakmar)

Imprimer le commentaire précédant l'opérateur pipeline sur sa propre ligne (#5015 par @flxwu)

Préserver les commentaires isolés dans les expressions `new` (#5017 par @flxwu)

Supprimer la protection ASI redondante pour les expressions bind (#4970 par @TitanSnow)

Ne pas supprimer les parenthèses nécessaires dans les expressions bind (#4964 par @TitanSnow)

Corriger l'indentation des ternaires dans les appels de fonction (#4368 par @malcolmsgroves)

Ne pas déplacer les commentaires dans les `import` (#5016 par @ericsakmar)

Corriger le commentaire instable dans `while` (#5251 par @jaideng123)

Imprimer stablement les commentaires entre la déclaration de fonction et son corps (#5250 par @jaideng123)

JSX

Ne pas casser les chaînes d'expressions logiques en JSX (#5092 par @duailibe)

Ne pas remplacer les espaces insécables par des espaces normaux (#5165 par @vjeux, #5334 par @ikatyang)

Ne pas casser les balises d'ouverture JSX simples (#5078 par @duailibe)

Corriger une régression pour les fonctions fléchées dans les expressions JSX (#5063 par @ikatyang)

Flow

Génériques en ligne avec un identifiant unique (#5066 par @duailibe)

Ne pas toujours mettre en ligne les classes dans `extends` (#5244 par @aquibm)

Ne pas ajouter de parenthèses inutiles pour les fonctions asynchrones dans `export default` (#5303 par @jbrown215)

TypeScript

Ajout d'une protection ASI pour les assertions non nulles (#5262 par @duailibe)

Ne pas ajouter de point-virgule supplémentaire pour les signatures de méthode avec `prettier-ignore` (#5160 par @onurtemizkan)

Ne pas imprimer de parenthèses invalides pour la déstructuration avec valeur par défaut (#5096 par @ikatyang)

Ne pas imprimer de point-virgule pour les propriétés de classe avec modificateurs en mode `--no-semi` (#5083 par @ikatyang)

Ne pas supprimer les parenthèses pour les nœuds complexes dans `extends` des ClassExpression (#5074 par @ikatyang)

Ne pas supprimer les parenthèses nécessaires pour TSOptionalType (#5056 par @ikatyang)

CSS

Ne pas imprimer de résultat incorrect en présence de front matter et `/* prettier-ignore */` (#5103 par @ikatyang)

Conserver les sauts de ligne dans les templates CSS-in-JS (#5240 par @onurtemizkan)

Markdown

Autoriser les espaces après les délimiteurs de front matters (#5107 par @ikatyang)

Ne pas ajouter d'espaces entre les caractères latins et hangul (#5040 par @ikatyang)

Préserver les sauts de ligne initiaux et finaux dans les blocs de code encadrés (#5038 par @ikatyang)

Formater en ligne les définitions de note de bas de page pour les paragraphes monolignes (#5025 par @ikatyang)

Formater correctement les listes précédant des sauts de ligne vides (#5024 par @ikatyang)

YAML

Échapper correctement les guillemets (#5236 par @ikatyang)

Préserver les commentaires finaux pour les documents et en-têtes (#5027 par @ikatyang)