Prettier 1.10 : Un an de Prettier 🎂
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 →
Joyeux anniversaire Prettier ! C'est assez incroyable que Prettier n'ait été publié qu'il y a un an et qu'il ait déjà connu une adoption massive et un grand nombre de contributeurs. Pour cette version spéciale, nous allons faire une petite rétrospective sur le projet.
C'est aussi une version excitante en soi car Prettier prend désormais partiellement en charge les fichiers .vue et son code interne a été remanié pour offrir une véritable API de plugin afin de supporter différents langages !
Rétrospective​
Depuis la sortie de gofmt en 2013, je (@vjeux) suis devenu obsédé par l'idée du formatage automatique. J'ai commencé à voir partout des problèmes qui seraient résolus par un formateur automatique : débats sur le style de code, obligation de formater manuellement le code, difficulté à écrire des outils de codemod…
Lorsque, en décembre dernier, pas moins de deux personnes travaillaient indépendamment sur un pretty printer JavaScript, c'était un signe ! Pieter Vanderwerff en a construit un en Reason basé sur l'infrastructure Flow et James Long en JavaScript. J'ai joué le rôle de cheerleader en mettant en place la même suite de tests pour les deux projets, ainsi qu'en exécutant leur pretty printer sur des bases de code existantes et en extrayant des listes de choses qui n'étaient pas bien formatées.
Malheureusement, après les vacances, tous deux ont dû retourner à leur vrai travail :( J'ai décidé de m'impliquer et de convaincre mon manager de me laisser y travailler à plein temps. James avait open sourcé son projet (Prettier) et j'étais plus familier avec JavaScript, j'ai donc décidé que c'est sur celui-ci que je travaillerais !
Voici une liste de quelques éléments qui ont bien fonctionné durant ce projet.
Passez du temps sur les notes de version​
Les notes de version ont une propriété intéressante : elles sont très souvent partagées, même si le contenu est mauvais. Tout le monde semble vouloir savoir que la version 1.5.8 d'un logiciel est sortie. C'est une très bonne occasion de promouvoir votre projet.
Pour les versions de Prettier, j'ai passé beaucoup de temps à expliquer la logique derrière chaque changement et à parler de choses qui auraient probablement fait l'objet d'un article de blog séparé (comme celui-ci !). De plus, vous aurez probablement la flemme et trouverez toutes les excuses du monde pour ne pas écrire cet article de blog, mais vous voulez vraiment publier cette nouvelle version, donc c'est un bon moyen de forcer les choses.
Processus décisionnel clair​
Les règles de style sont l'un des sujets les plus controversés et en même temps beaucoup de décisions devaient être prises. J'ai essayé de concevoir un processus décisionnel qui nous permettrait de progresser.
Les gens trouvent toutes sortes d'arguments émotionnels pour vous convaincre que leur opinion sur le style est la meilleure. Nous avions besoin d'avoir quelque chose de purement rationnel pour que, même si ce n'est pas ce que les gens préfèrent, ils ne puissent pas contester la méthodologie.
Le meilleur que j'ai pu trouver était de compter combien de fois chaque variante était utilisée dans la base de code de Facebook. C'est facile pour moi de lancer cela et de fournir des nombres relatifs (le style A est utilisé 5 fois plus que le style B) pour convaincre les gens. Si une base de code aussi grande, écrite par des milliers de personnes au fil des ans, a un gagnant, ce n'est peut-être pas le meilleur mais cela ne sera probablement pas très controversé.
Tout ne pouvait pas être résolu de cette manière, certaines choses n'avaient pas de gagnant clair ou il n'était pas évident de trouver un algorithme pour bien les formater. Dans ces cas, il était important d'avoir un processus d'escalade avec une seule personne prenant la décision finale (moi). De cette façon, nous pouvions progresser sans avoir besoin de trouver un consensus, ce qui aurait probablement été très difficile.
L'open source comme cobaye​
Un formateur de code complet est l'un de ces projets qui doit être quasi parfait pour être déployé sur une base de code importante comme Facebook. La première impression est extrêmement importante, et il est très difficile d'obtenir un résultat correct (qui ne produira pas de JavaScript invalide ni de code ayant un comportement différent) pour tous les cas particuliers.
Mon plan initial était de travailler seul dessus, caché du monde extérieur pendant 6 mois, jusqu'à ce que tout soit parfait, avant de le proposer aux utilisateurs. Ce que je n'avais pas prévu, c'est que les contributeurs open source n'avaient pas les mêmes exigences de qualité et ont commencé à l'utiliser bien plus tôt. Les risques d'utilisation sur un projet personnel sont radicalement différents que sur des millions de lignes de code chez Facebook.
Cela s'est finalement avéré très bénéfique pour le projet d'obtenir des retours progressifs jusqu'à ce qu'il soit prêt pour Facebook.
L'open source comme source de contributeurs​
Pendant les 6 premiers mois du projet, j'y ai travaillé à plein temps mais je n'ai rédigé que la moitié des commits. C'est déjà assez incroyable en soi ! Non seulement le débit était deux fois supérieur, mais les contributeurs ont travaillé sur des aspects que je n'aurais pas priorisés : intégrations avec tous les éditeurs existants, fuzzer pour détecter les bugs, support TypeScript, infrastructure pour analyser plusieurs langages dans un même fichier, etc.
Même si nous n'utilisons pas tout cela chez Facebook, beaucoup se sont révélés utiles. Le support CSS-in-JS a facilité le formatage des fragments GraphQL dans les littéraux de template. Le grand nombre d'utilisateurs a aussi permis de remonter des bugs obscurs que nous aurions fini par rencontrer, et diverses personnes ont contribué à les corriger.
Le plus formidable, c'est que j'ai quitté le projet à plein temps il y a 6 mois, et qu'il a continué sous la direction de @azz. Je tiens à remercier toutes les personnes qui ont aidé de diverses manières - c'est tellement excitant d'écrire l'histoire ensemble !
L'open source a fait des merveilles pour le projet, apportant une énorme valeur à Facebook (presque tous nos fichiers JavaScript sont maintenant formatés) et à l'industrie entière comme en témoigne l'adoption massive.
Outillage : Tests par snapshot Jest & Playground​
Toutes ces contributions ont été possibles grâce à la simplicité pour signaler des erreurs, contribuer et relire le code. Les deux outils les plus impactants furent les tests par snapshot Jest et le playground.
Les tests par snapshot sont merveilleux pour un formateur de code. Ajouter de nouveaux tests est d'une simplicité enfantine : créez un fichier dans le dossier test avec le code à formater, lancez Jest, et voilà ! À chaque modification, vous voyez comment de nombreux exemples seraient formatés différemment, puis vous décidez si c'est mieux. Pour un relecteur, c'est idéal : vous voyez l'avant/après de tous les changements. J'en suis venu à accorder plus d'attention aux snapshots qu'à l'implémentation réelle.
Le playground est un excellent moyen d'obtenir un repro ou d'expérimenter Prettier sans installer l'environnement de développement ni être sur la bonne branche. Il s'est avéré extrêmement précieux pour obtenir des rapports de bugs actionnables et de qualité.
Principales fonctionnalités​
Support des composants monofichiers Vue (#3563) par @vjeux​
La demande pour les SFC Vue est importante (#2097). Nous avons introduit un support partiel : tout le HTML est imprimé tel quel, mais désormais les balises <script> et <style> sont formatées par Prettier.
Pour l'utiliser, exécutez simplement prettier sur vos fichiers *.vue !
API de plugins Prettier (#3536) par @azz​
Alors que Prettier pour JavaScript est devenu stable, nous avons récemment vu des contributeurs souhaitant ajouter de nouveaux langages à Prettier, notamment avec des demandes d'ajout pour Python et PHP. Nous voulons garder le paquet principal prettier portable et maintenable, tout en offrant la possibilité d'exécuter Prettier sur plus de langages. Pour cela, nous avons introduit une [API de plugins] ! Les plugins Prettier peuvent contribuer des parseurs et/ou des printers au formateur Prettier. Ils sont traités comme des citoyens de première classe et peuvent même contribuer au support d'imbrication (par exemple, formater votre langage dans du Markdown).
Utiliser des plugins est aussi simple que de les installer via npm/yarn, puis d'exécuter Prettier comme d'habitude, sans configuration supplémentaire à gérer !
Trois plugins officiels sont en développement :
Ces trois plugins sont encore en développement actif et ne sont pas prêts pour la production, mais gardez un œil sur eux car ils progressent rapidement !
Si vous souhaitez contribuer à ces plugins, consultez les issues de leurs dépôts ou testez-les sur votre code pour remonter des bugs ! De même, si vous voulez ajouter un nouveau langage à Prettier et avez besoin d'aide pour démarrer, créez une issue dans le dépôt prettier et nous vous aiderons.
Les langages intégrés à Prettier ont été refactorisés pour utiliser l'API de plugins, garantissant ainsi que l'API centrale reste générique à l'avenir.
Consultez [la documentation][plugin api] pour plus d'informations.
Veuillez noter qu'il s'agit d'une nouvelle fonctionnalité majeure, que nous publions avec un label bêta dans la documentation. Bien que nous n'anticipions rien de critique, cela signifie que nous pourrions apporter des changements cassants dans la prochaine version.
Autres changements​
TypeScript​
Prise en charge des séparateurs numériques (#3580) par @azz​
Les séparateurs numériques sont une proposition ECMAScript de stage 3. Leur support a été ajouté dans TypeScript 2.7, et Prettier les préservera désormais.
// Before
SyntaxError: ',' expected. (1:10)
> 1 | var a = 1_000_000_000;
| ^
2 | var b = 0b1101_0101_1001;
3 | var c = 0xAE_FE_2F;
// After
var a = 1_000_000_000;
var b = 0b1101_0101_1001;
var c = 0xAE_FE_2F;
Flow​
Imprimer les annotations de type Flow comme commentaires (#3449) par @duailibe​
Les commentaires d'annotation de type de Flow permettent de bénéficier du typage sans transpilation. Avant cette version, Prettier avec le parseur Flow n'imprimait pas ces annotations comme commentaires, rendant cette fonctionnalité inutilisable. Désormais, Prettier détecte correctement les annotations de type commentées et les imprime pour /*: ... */. Le support pour /*:: ... */ est en cours.
// Input
let foo: string = "a";
// Before
let foo: string = "a";
// After
let foo: string = "a";
Imprimer les commentaires après les paramètres des fonctions fléchées (#3444) par @duailibe​
Avec le parseur babylon, divers problèmes déplaçaient les commentaires Flow. L'un d'eux a été corrigé dans cette version. Nous nous rapprochons ainsi du support complet de cette fonctionnalité.
// Before
const run = (cmd /*: string */ /*: Promise<void> */) => {};
// After
const run = (cmd /*: string */) /*: Promise<void> */ => {};
Imprimer les parenthèses dans FunctionTypeAnnotation quand arrowParens est "always" (#3616) par @duailibe​
Dans la dernière version, nous avons ajouté l'option arrowParens. Son application avait été omise pour les annotations de type fonction Flow. Maintenant, quand arrowParens est défini sur always, nous ajoutons des parenthèses autour des arguments uniques.
// --arrow-parens always
// Before
type SomeType = {
something: number => number
};
// After
type SomeType = {
something: (number) => number
};
JSX​
Expressions do inline dans JSX (#3607) par @vjeux​
Les "do expressions" sont une proposition ECMAScript stage 1, particulièrement utiles en JSX. Nous avons supprimé le niveau d'indentation supplémentaire pour les intégrer directement dans le conteneur d'expressions.
// Before
{
do {
// ...
}
}
// After
{do {
// ...
}}
Empêche l'ajout d'une softline après un attribut fléché avec des commentaires (#3641) par @duailibe​
Correction d'un problème mineur où un saut de ligne supplémentaire apparaissait dans les attributs JSX.
// --print-width 13 (for demonstration)
// Before
<span
attr={
// comment
() =>
true
}
/>;
// After
<span
attr={
// comment
() =>
true
}
/>;
Ne pas encapsuler les éléments JSX en attributs dans () (#3640) par @duailibe​
La spécification JSX permet secrètement de passer un élément comme attribut à un autre élément. Prettier ajoutait des parenthèses causant une erreur syntaxique, désormais corrigée. Note : bien que certains analyseurs syntaxiques prennent cette fonctionnalité en charge, aucune transformation JSX ne l'autorise actuellement. Le premier support prévu sera dans Babel 7 (actuellement en bêta).
// Before
<Foo
content=(
<div>
<div />
</div>
)
/>
// After
<Foo
content=<div>
<div />
</div>
/>
SCSS​
Conserver les commentaires dans les sélecteurs (#3649) par @vjeux​
Notre analyseur CSS pour les sélecteurs ne gère pas les commentaires, ce qui pouvait déplacer des commentaires sur des lignes inappropriées. Ce comportement est maintenant corrigé.
/* Before */
// Foo
.foo,
// Bar .bar {
display: block;
}
/* After */
// Foo
.foo,
// Bar
.bar {
display: block;
}
GraphQL​
Mise à jour de l'analyseur GraphQL (#3605) par @vjeux​
Prettier prend désormais en charge les trois nouvelles fonctionnalités de la spécification GraphQL :
Annotation des types avec des descriptions textuelles
"""
Type description
"""
type Foo {
"some description"
someProperty: String!
"""
some really
long description
"""
someOtherProperty: [String!]!
}
Omettre {} quand le contenu est vide
extend enum Site @onEnum
Possibilité d'étendre tous les types
extend input InputType {
other: Float = 1.23e4
}
Markdown​
Remplacer les sauts de ligne dans les multiparseurs (#3611) par @ikatyang​
Correction d'un problème où le caractère > des citations disparaissait lors de l'insertion de JavaScript dans un bloc Markdown.
<!-- before -->
> ````md
> <!-- prettier-ignore -->
> ```js
ugly ( code ) ;
```
> ````
<!-- after -->
> ````md
> <!-- prettier-ignore -->
> ```js
> ugly ( code ) ;
> ```
> ````
Respecter l'option singleQuote dans les titres de liens Markdown (#3481) par @j-f1​
Précédemment, tous les titres de liens étaient entre guillemets ". Désormais, ils respectent l'option singleQuote. Nous utiliserons des guillemets de style () si le titre contient à la fois ' et ".
<!-- --single-quote -->
<!-- Before -->
[ref]: https://prettier.io "Prettier"
[other-ref]: https://example.com "Shakespeare's \"Romeo and Juliet\" is a famous play"
<!-- after -->
[ref]: https://prettier.io 'Prettier'
[other-ref]: https://example.com (Shakespeare's "Romeo and Juliet" is a famous play)
Gérer les références d'images sans alt en Markdown (#3643) par @duailibe​
Correction d'un cas limite où Prettier plantait avec des références d'images sans texte alternatif.
<!-- before -->
TypeError: doc is null
<!-- after -->
![][logo]
[logo]: https://github.com/prettier/prettier-logo/blob/master/images/prettier-logo-light.png?raw=true
Respecter tabWidth pour l'indentation des listes (#3694) par @ikatyang​
L'indentation des listes respecte désormais tadWidth au lieu d'imposer systématiquement 2 espaces.
<!-- --tab-width 4 -->
<!-- before -->
* one
* two
<!-- after -->
* one
* two
API​
Ajouter le champ options à getSupportInfo() (#3433) par @ikatyang​
prettier.getSupportInfo().options contient maintenant un tableau des options supportées.
Limiter la recherche des .editorconfig au répertoire VCS (#3559) par @josephfrazier​
Il peut être assez déroutant de diagnostiquer un problème où Prettier formate le code différemment entre deux personnes ayant le même dépôt. Parce que Prettier prend en charge les fichiers .editorconfig, et que nous cherchions jusqu'au fichier ~/.editorconfig, cela a eu l'effet secondaire involontaire de modifier la mise en forme du code de certaines personnes. Nous ne regardons désormais que jusqu'au répertoire racine de votre projet.
CLI​
Centraliser les logs CLI via un logger (#3515) par @azz​
L'option --loglevel n'était pas respectée dans certains cas, elle est désormais appliquée pour toute la journalisation CLI.
# Before
$ prettier --loglevel silent --write test.js
test.js 91ms
# After
$ prettier --loglevel silent --write test.js
Sortir les fichiers tels quels s'ils sont ignorés (#3618) par @duailibe​
Nous avons corrigé le comportement du CLI concernant les fichiers ignorés. Auparavant, lorsqu'un fichier était ignoré via .prettierignore, le CLI ne produisait aucune sortie. Ce comportement affectait les intégrations d'éditeurs. Le comportement est maintenant :
-
Avec
--write, ne pas lire ni écrire dans le fichier ignoré. -
Sans
--write, lire le fichier ignoré et le sortir tel quel.
Intégrations d'éditeurs​
Ajout des extensions PostCSS à getSupportInfo() (#3454) par @ardevelop​
Certaines intégrations d'éditeurs utilisent la fonction getSupportInfo de Prettier pour supporter dynamiquement tous les langages. Ce changement ajoute le support des fichiers *.pcss.
Ajout du "JSON avec commentaires" à getSupportInfo() (#3496) par @thorn0​
De même, le "JSON avec commentaires" sera désormais détecté.