Prettier 1.8 : Prise en charge du Markdown

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 Markdown, un nouveau drapeau --insert-pragma, corrige plusieurs problèmes de mise en forme, ajoute la prise en charge de nouveaux opérateurs expérimentaux, et améliore notre support d'intégration aux éditeurs.

Principales fonctionnalités

Prise en charge du Markdown

Support markdown (#2943) par @ikatyang

Vous pouvez désormais exécuter Prettier sur des fichiers Markdown ! 🎉

L'implémentation est hautement conforme à la spécification CommonMark, et s'appuie sur l'excellent package remark-parse.

Retour à la ligne

L'une des fonctionnalités clés de Prettier est sa capacité à ajuster le code à une longueur de ligne spécifiée. Cela s'applique aussi au Markdown, ce qui vous permet de maintenir des fichiers Markdown propres sur 80 caractères de large sans avoir à réajuster manuellement les sauts de ligne lorsque vous ajoutez ou supprimez des mots.

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 :

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 : Nous envisageons d'ajouter une option pour cela, consultez #3183 pour la discussion. Mise à jour : Nous avons ajouté une option dans 1.8.2 appelée --no-prose-wrap

Note pour les utilisateurs CJK : Si votre rendu Markdown ne prend pas en charge les fins de ligne CJK, vous devrez utiliser des plugins comme markdown-it-perfect-newline-for-cjk, hexo-filter-fix-cjk-spacing, etc. pour supprimer les espaces supplémentaires.

// Source
一二三
四五六
七八九

// Rendered content with unsupported renderer
一二三 四五六 七八九

// Rendered content with supported renderer or via plugin
一二三四五六七八九

Formatage du code

Grâce au "multiparser" générique de Prettier, Prettier formatera les blocs de code dans Markdown ! Nous utilisons le langage indiqué avec le bloc de code pour déterminer le langage, ce qui nous permet de formater tout langage supporté par Prettier (y compris Markdown lui-même, si cela vous intéresse).

Entrée :

```js
reallyUgly    (
javascript
  )
```

```css
.h1 {     color : red }
```

Sortie :

```js
reallyUgly(javascript);
```

```css
.h1 {
  color: red;
}
```

Note : Dans certains cas, vous ne voudrez peut-être pas formater votre code dans Markdown. Comme pour les autres langages, vous pouvez utiliser un commentaire d'ignorance avant le bloc de code pour l'exclure du formatage :

<!-- prettier-ignore -->
```js
ugly   ( code ) ;
```

Listes

Lorsque vous réorganisez des éléments de liste, Prettier corrigera automatiquement tous les numéros !

Note : vous pouvez désactiver ce comportement en utilisant 1. pour tous les éléments de liste si vous souhaitez optimiser pour des diffs plus propres.

Tableaux

Les tableaux seront également ajustés automatiquement pour s'adapter à leur contenu. Cela pourrait devenir totalement ingérable sans un outil automatisé.

Markdown dans JavaScript

En utilisant les littéraux de gabarits étiquetés md ou markdown, vous pouvez formater du code Markdown dans JavaScript.

const markdown = md`
  # heading

  1. list item
`;

CLI

Ajout d'une option pour insérer @format dans le premier bloc de documentation si absent (#2865) par @samouri

Dans la version 1.7, nous avions ajouté une option --require-pragma exigeant la présence d'un pragma /** @format */ dans les fichiers à formater. Pour ajouter ce pragma à un grand ensemble de fichiers, vous pouvez désormais utiliser le drapeau --insert-pragma.

prettier --write "folder/**/*.js" --insert-pragma

Ajout de l'option --loglevel (#2992) par @ikatyang

Cette fonctionnalité pratique permet d'activer (ou désactiver) les logs de Prettier. Nous avons également nettement amélioré le système de journalisation depuis la version 1.7.

$ prettier --loglevel=debug blarg
$ ./bin/prettier.js --loglevel=debug blarg
[debug] normalized argv: {"_":["blarg"],"bracket-spacing":false,"color":true,"debug-check":false,"debug-print-doc":false,"flow-parser":false,"insert-pragma":false,"jsx-bracket-same-line":false,"list-different":false,"require-pragma":false,"semi":false,"single-quote":false,"stdin":false,"use-tabs":false,"version":false,"with-node-modules":false,"write":false,"loglevel":"debug","ignore-path":".prettierignore","config-precedence":"cli-override"}
[error] No matching files. Patterns tried: blarg !**/node_modules/** !./node_modules/**

JavaScript

Correction de l'indentation pour les commentaires JSDoc (#2470) par @maxdeviant

C'était un problème connu de longue date avec Prettier. Lors du formatage de code modifiant le niveau d'indentation, les commentaires JSDoc se retrouvaient désalignés. Nous sommes heureux d'annoncer que ce problème est désormais résolu !

// Before
function theFunction2(action$, store) {
  /*
     * comments
     */
  return true;
}

// After
function theFunction2(action$, store) {
  /*
   * comments
   */
  return true;
}

Prise en charge des opérateurs pipeline et de coalescence des nuls (#3036) par @azz

Nous avons ajouté le support de deux nouveaux opérateurs proposés à Prettier : l'opérateur pipeline et l'opérateur de coalescence des nuls.

L'opérateur pipeline est actuellement une proposition de stage 1.

Cette proposition introduit un nouvel opérateur |> similaire à ceux de F#, OCaml, Elixir, Elm, Julia, Hack et LiveScript, ainsi qu'aux pipes UNIX. C'est une manière rétrocompatible de simplifier les chaînages d'appels de fonctions de façon lisible et fonctionnelle, offrant une alternative pratique à l'extension des prototypes natifs.

// Before
let result = exclaim(capitalize(doubleSay("hello")));

// After
let result = "hello"
  |> doubleSay
  |> capitalize
  |> exclaim;

L'opérateur de coalescence des nuls est une autre proposition de stage 1.

Lors d'un accès conditionnel à une propriété imbriquée avec l'opérateur de chaînage optionnel, il est souvent souhaitable de fournir une valeur par défaut si le résultat est null ou undefined.

Cet opérateur est similaire à || mais n'évalue le côté droit que si le gauche est undefined ou null, et non "", 0, NaN, etc.

const foo = object.foo ?? "default";

Amélioration des sauts de ligne dans les expressions de littéraux de gabarits (#3124) par @duailibe

C'était un autre problème connu : lors de l'impression de chaînes de gabarits contenant des expressions dépassant la largeur définie, les sauts de ligne se produisaient à des endroits inappropriés. Désormais, si Prettier doit insérer un saut de ligne, celui-ci se produit précisément entre ${ et }.

// Before
const description = `The value of the ${cssName} css of the ${this
  ._name} element`;

const foo = `mdl-textfield mdl-js-textfield ${className} ${content.length > 0
  ? "is-dirty"
  : ""} combo-box__input`;

// After
const description = `The value of the \${cssName} css of the \${
  this._name
} element`;

const foo = `mdl-textfield mdl-js-textfield ${className} ${
  content.length > 0 ? 'is-dirty' : ''
} combo-box__input`

JSX

Ne pas aligner la } de fin pour les attributs de fonctions fléchées (#3110) par @duailibe

Pour mieux respecter le guide de style Airbnb et puisque ce formatage n'était pas intentionnel, nous avons déplacé le } sur la ligne suivante dans le JSX. Cela améliore la lisibilité des diffs et facilite le déplacement du code par décalage de lignes dans votre éditeur.

// Before
<BookingIntroPanel
  logClick={data =>
    doLogClick("long_name_long_name_long_name", "long_name_long_name_long_name", data)}
/>;

// After
<BookingIntroPanel
  logClick={data =>
    doLogClick("long_name_long_name_long_name", "long_name_long_name_long_name", data)
  }
/>;

Autres changements

JavaScript

Faire en sorte que la détection d'usine gère plusieurs éléments (#3112) par @vjeux

Il y avait un bogue dans l'heuristique que Prettier utilise pour déterminer si une expression est une factory ou non. Cela fonctionne désormais correctement avec les expressions de membre plus longues.

// Before
window.FooClient
  .setVars({
    locale: getFooLocale({ page }),
    authorizationToken: data.token
  })
  .initVerify("foo_container");

// After
window.FooClient.setVars({
  locale: getFooLocale({ page }),
  authorizationToken: data.token
}).initVerify("foo_container");

Gérer les commentaires entre le nom de la fonction et la parenthèse ouvrante (#2979) par @azz

Placer les commentaires au bon endroit est un défi sans fin 😉. Cette correction garantit que les commentaires à côté des noms de fonction sont correctement réimprimés.

// Before
function f(/* comment*/ promise) {}

// After
function f /* comment*/(promise) {}

Prendre en charge les CallExpressions séquentielles dans les chaînes de membres (#2990) par @chrisvoll

Les chaînes de membres sont l'une des parties les plus complexes de Prettier. Cette PR corrige un problème où des appels répétés empêchaient la méthode suivante d'être repoussée à la ligne suivante.

// Before
wrapper
  .find("SomewhatLongNodeName")
  .prop("longPropFunctionName")().then(function() {
  doSomething();
});

// After
wrapper
  .find("SomewhatLongNodeName")
  .prop("longPropFunctionName")()
  .then(function() {
    doSomething();
  });

Prendre en compte les lignes vides dans les longues chaînes d'appels de membres (#3035) par @jackyho112

Auparavant, Prettier supprimait toutes les nouvelles lignes dans une chaîne de membres. Maintenant nous en conservons une si elle est présente dans la source. C'est pratique pour les API fluides que vous souhaitez répartir sur plusieurs lignes.

angular
  .module("AngularAppModule")

  // Constants.
  .constant("API_URL", "http://localhost:8080/api")

  // App configuration.
  .config(appConfig)
  .run(appRun);

Corriger un problème où le premier argument était laissé de côté lors des sauts de ligne (#3079) par @mutdmour

Cela corrige un problème où, en raison de notre comportement spécial d'alignement d'objets, l'indentation manquait dans l'appel de fonction.

// Before
db.collection("indexOptionDefault").createIndex({ a: 1 },
{
  indexOptionDefaults: true
},
function(err) {
  // code
});

// After
db.collection("indexOptionDefault").createIndex(
  { a: 1 },
  {
    indexOptionDefaults: true
  },
  function(err) {
    // code
  }
);

Rompre les parenthèses pour les binaires dans les expressions de membre (#2958) par @duailibe

De même, il y avait un autre cas limite où l'indentation manquait dans les expressions logiques. Cela est également corrigé.

// Before
const someLongVariable = (idx(
  this.props,
  props => props.someLongPropertyName
) || []
).map(edge => edge.node);

// After
const someLongVariable = (
  idx(this.props, props => props.someLongPropertyName) || []
).map(edge => edge.node);

Empêcher la rupture de MemberExpression à l'intérieur de NewExpression (#3075) par @duailibe

Il existe tellement de façons de rompre une ligne. Certaines sont bien pires que d'autres. Dans ce cas, la rupture avait l'air vraiment étrange, donc cela a été corrigé !

// Before
function functionName() {
  if (true) {
    this._aVeryLongVariableNameToForceLineBreak = new this
      .Promise((resolve, reject) => {
        // do something
      });
  }
}

// After
function functionName() {
  if (true) {
    this._aVeryLongVariableNameToForceLineBreak = new this.Promise(
      (resolve, reject) => {
        // do something
      }
    );
  }
}

Corriger les accesseurs de tableau dans les chaînes de méthodes (#3137) par @duailibe

Dans une chaîne de méthodes, nous divisons les lignes en regroupant les éléments ensemble et l'accès à un tableau doit être imprimé à la fin d'un groupe plutôt qu'au début.

// Before
find('.org-lclp-edit-copy-url-banner__link')
  [0].getAttribute('href')
  .indexOf(this.landingPageLink)

// After
find('.org-lclp-edit-copy-url-banner__link')[0]
  .getAttribute('href')
  .indexOf(this.landingPageLink)

Flow et TypeScript

Corriger l'indentation des types d'objets d'intersection (#3074) par @duailibe

C'était un bogue mineur d'alignement dans les types d'intersection, et il a maintenant été corrigé.

// Before
type intersectionTest = {
  propA: X
} & {
  propB: X
} & {
    propC: X
  } & {
    propD: X
  };

// After
type Props = {
  propA: X
} & {
  propB: X
} & {
  propC: X
} & {
  propD: X
};

Conserver les parenthèses autour de TSAsExpression dans ConditionalExpression (#3053) par @azz

Nous avions manqué un cas où nous devions conserver les parenthèses avec les assertions as de TypeScript. C'est maintenant corrigé.

// Before
aValue as boolean ? 0 : -1;

// After
(aValue as boolean) ? 0 : -1;

JSX

Réduire les espaces blancs multiples en JSX (#2973) par @karl

Ceci corrige le problème où la mise en forme JSX nécessitait parfois d'être exécutée deux fois pour se stabiliser. Cela se produisait lorsqu'il y avait plusieurs éléments d'espacement JSX ou un espacement JSX suivi d'un espace.

// Before
<div>
    {" "} <Badge src={notificationIconPng} />
</div>;

// After
<div>
  {" "}
  <Badge src={notificationIconPng} />
</div>

Ne pas imprimer le crochet JSX sur la même ligne lorsqu'il contient des commentaires de fin (#3088) par @azz

Il s'agissait d'un problème avec l'option --jsx-bracket-same-line. Il s'avère qu'on ne peut pas toujours placer le crochet sur la même ligne...

// Input
<div
  // comment
>
  {foo}
</div>

// Before
<div>
// comment
  {foo}
</div>;

// After
<div
// comment
>
  {foo}
</div>;

CSS

Préserver les sauts de ligne dans les déclarations grid (#3133) par @duailibe

Prettier préservera désormais les sauts de ligne présents dans le code source lors de la mise en forme des règles grid et grid-template-*, car il est important de les conserver sur des lignes séparées, tout en appliquant la mise en forme comme pour les autres règles (par exemple, les nombres et les guillemets).

/* Original Input */
div {
  grid:
    [wide-start] 'header header header' 200.000px
    [wide-end] "footer footer footer" .50fr
    / auto 50.000px auto;
}

/* Before */
div {
  grid: [wide-start] "header header header" 200px [wide-end]
    "footer footer footer" 0.5fr / auto 50px auto;
}

/* After */
div {
  grid:
    [wide-start] "header header header" 200px
    [wide-end] "footer footer footer" 0.5fr
    / auto 50px auto;
}

SCSS

Formater les maps SCSS comme des règles CSS (#3070) par @asmockler

Il s'avère que les maps SCSS sont bien plus élégants lorsqu'ils sont imprimés sur plusieurs lignes.

// Before
$map: (color: [#111111](https://github.com/prettier/prettier/pull/111111), text-shadow: 1px 1px 0 salmon)

// After
$map: (
  color: [#111111](https://github.com/prettier/prettier/pull/111111),
  text-shadow: 1px 1px 0 salmon
);

CSS-in-JS

Corriger la mise en forme de styled(Foo).attrs(...)`` (#3073) par @existentialism

Prettier formatera désormais le CSS dans le code styled-components qui ressemble à ceci :

styled(Component).attrs({})`
  color: red;
`;

GraphQL

Empêcher la mise en forme des littéraux de modèle GraphQL avec expressions (#2975) par @duailibe

Prettier ne prend pas en charge la mise en forme des expressions JavaScript dans GraphQL. Voir #2640 pour le suivi. Un bug survenait lorsque la mise en forme d'une expression produisait un code invalide, nous avons donc complètement désactivé la mise en forme de GraphQL lorsqu'il contient des expressions JavaScript jusqu'à ce que nous le prenions pleinement en charge.

// Before
(invalid code)

// After
graphql(schema, `{ query test { id }} ${fragment}`)

CLI

Ne pas utiliser de codes ANSI si stdout n'est pas un TTY (#2903) par @Narigo

Auparavant, rediriger la sortie de --list-different vers d'autres outils était problématique à cause des codes couleur ANSI utilisés pour indiquer si un fichier était modifié. Cette PR désactive l'utilisation des couleurs lorsque la sortie de Prettier est redirigée vers un autre processus.

Configuration

Utiliser des chemins relatifs avec le CLI (#2969) par @ahmedelgabri

Ceci corrige un bug où passer un chemin commençant par ./ au CLI ne correspondait pas aux motifs utilisés dans .prettierignore.

## .prettierignore
path/to/*.js

Après ce correctif, aucun fichier ne sera écrit lors de l'exécution de :

$ prettier --write ./path/to/*.js

Résoudre les chemins de fichiers relatifs au fichier de configuration (#3037) par @azz

Ceci corrige un problème où les substitutions dans .prettierrc, dans certaines conditions, n'étaient pas respectées pour les chemins absolus avec l'API resolveConfig.

Core

Respect de la largeur CJK et des caractères combinés (#3003, #3015) par @ikatyang

Les caractères chinois, japonais et coréens (CJK) sont désormais considérés comme ayant une largeur équivalente à deux caractères.

// Before (exceeds print width when CJK characters are 2x monospace chars)
const x = ["中文", "中文", "中文", "中文", "中文", "中文", "中文", "中文", "中文", "中文", "中文"];

// After
const x = [
  "中文",
   // ...
  "中文"
];

##3015 garantit également que les caractères combinés (par exemple Á) soient comptabilisés comme un seul caractère.

Support des éditeurs

Implémentation de getSupportInfo() et utilisation pour l'inférence (#3033) par @azz

Nous avons ajouté une nouvelle fonction à l'API (prettier.getSupportInfo([version])) ainsi que l'option CLI --support-info. Ces outils permettent d'interroger Prettier pour déterminer quels langages sont pris en charge par la version actuelle ou une version antérieure. Ils fournissent également des informations utiles comme les identifiants CodeMirror, les tmScopes, etc., qui peuvent automatiser certaines tâches dans les intégrations d'éditeurs de texte.

En interne, nous utilisons ces informations pour déterminer quelles extensions activent quels analyseurs syntaxiques, et prenons en charge certains fichiers courants sans extension comme .prettierrc, Jakefile, etc.

## prettier knows that this file is JSON now.
$ prettier --write .prettierrc

Séparation des éléments sources selon leur langage (#3069) par @CiGit

Ce correctif résout un problème dans les éditeurs prenant en charge le formatage par plage, où le formatage d'un objet pouvait provoquer un plantage de Prettier.

---

Merci ! ❤️

Merci à toutes les personnes qui ont contribué à cette version, ainsi qu'à celles qui ont signalé des problèmes ! Prettier est devenu un logiciel extrêmement stable auquel un grand nombre de personnes confient leur code. Nous prenons cette confiance très au sérieux et corrigeons en priorité les rares problèmes pouvant altérer le code. Nous ne pouvons résoudre ces problèmes sans les connaître, alors n'hésitez jamais à créer une issue !