Prettier 1.10: Ein Jahr Prettier 🎂
Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →
Frohen Prettier-Geburtstag! Es ist ziemlich unglaublich, dass Prettier erst vor einem Jahr veröffentlicht wurde und bereits eine so massive Verbreitung und so viele Mitwirkende gefunden hat. Zu diesem besonderen Release möchten wir einen kleinen Rückblick auf das Projekt geben.
Dieses Release ist auch an sich aufregend, denn Prettier unterstĂĽtzt jetzt teilweise .vue-Dateien und die internen Strukturen wurden so ĂĽberarbeitet, dass es eine ordentliche Plugin-API gibt, um verschiedene Sprachen zu unterstĂĽtzen!
Rückblick​
Seit gofmt 2013 erschien, war ich (@vjeux) vom Konzept der automatischen Formatierung besessen. Ich sah ständig Probleme, die durch einen automatischen Formatter gelöst würden: Diskussionen über Codierungsstile, manuelles Formatieren von Code, Schwierigkeiten beim Schreiben von Codemod-Tools…
Als letzten Dezember nicht eine, sondern zwei Personen unabhängig voneinander an einem JavaScript-Pretty-Printer arbeiteten, war das ein Zeichen! Pieter Vanderwerff baute einen in Reason basierend auf der Flow-Infrastruktur und James Long in JavaScript. Ich übernahm die Rolle des Cheerleaders, indem ich dieselbe Testsuite für beide Projekte einrichtete, ihren Pretty-Printer auf existierenden Codebasen laufen ließ und Listen von Dingen erstellte, die nicht gut formatiert wurden.
Leider mussten beide nach den Feiertagen zu ihrer eigentlichen Arbeit zurĂĽckkehren :( Ich beschloss einzuspringen und meinen Manager zu ĂĽberzeugen, Vollzeit daran zu arbeiten. James hatte sein Projekt (Prettier) quelloffen gemacht und ich war mit JavaScript vertrauter, also entschied ich mich fĂĽr dieses!
Hier sind einige Dinge, die bei diesem Projekt gut funktioniert haben:
Zeit für Release Notes investieren​
Release Notes haben die interessante Eigenschaft, dass sie sehr oft geteilt werden – selbst wenn der Inhalt schlecht ist. Jeder scheint wissen zu wollen, dass Version 1.5.8 einer Software erschienen ist. Das ist eine hervorragende Gelegenheit, um auch für dein Projekt zu werben.
Für Prettier-Releases habe ich viel Zeit darauf verwendet, die Hintergründe aller Änderungen zu erklären und über Dinge zu sprechen, die sonst wahrscheinlich als separater Blogpost erschienen wären (wie dieser!). Außerdem neigt man dazu, faul zu sein und Ausreden zu finden, um diesen Blogpost nicht zu schreiben – aber man möchte unbedingt die neue Version veröffentlichen, also ist das ein guter Zwang.
Klarer Entscheidungsprozess​
Stilregeln gehören zu den umstrittensten Themen, und gleichzeitig mussten viele Entscheidungen getroffen werden. Ich versuchte, einen Entscheidungsprozess zu gestalten, der uns Fortschritte ermöglicht.
Menschen finden alle möglichen emotionalen Argumente, um zu überzeugen, dass ihre Stilmeinung die beste sei. Wir brauchten etwas rein Rationales, damit Leute – selbst wenn es nicht ihre Präferenz war – nicht gegen die Methodik argumentieren konnten.
Die beste Lösung war, zu zählen, wie oft jede Variante in der Facebook-Codebase verwendet wurde. Ich kann das leicht ausführen und relative Zahlen liefern (Stil A wird 5x häufiger verwendet als Stil B), um Leute zu überzeugen. Wenn ein so großer Codebase, der über Jahre von Tausenden geschrieben wurde, einen Gewinner hat, mag er nicht perfekt sein, aber er wird wahrscheinlich nicht massiv umstritten sein.
Nicht alles ließ sich so lösen – manches hatte keinen klaren Gewinner, oder es war nicht offensichtlich, wie ein guter Formatierungsalgorithmus aussehen sollte. In solchen Fällen war ein Eskalationsprozess wichtig, bei dem am Ende eine einzelne Person (ich) die Entscheidung traf. So konnten wir Fortschritte machen, ohne einen Konsens finden zu müssen, was sehr schwierig geworden wäre.
Open Source als Versuchskaninchen​
Ein vollständiger Pretty-Printer ist eines dieser Projekte, das nahezu perfekt sein muss, um es in einer großen Codebase wie Facebook einzusetzen. Der erste Eindruck ist extrem wichtig, und es ist sehr schwer, etwas zu schaffen, das korrekt ist (es führt kein ungültiges JavaScript ein oder Code, der sich anders verhält) – für alle Randfälle.
Mein ursprünglicher Plan war, es sechs Monate lang allein in einer Höhle verborgen vor der Außenwelt zu bearbeiten, bis alles perfekt wäre, und es dann zur Nutzung freizugeben. Was ich nicht erwartete: Leute in Open Source hatten nicht dieselbe Qualitätslatte und begannen viel früher damit. Die Risiken bei einem Nebenprojekt sind völlig anders als bei Millionen Codezeilen bei Facebook.
Es erwies sich als sehr vorteilhaft für das Projekt, währenddessen Feedback zu erhalten, bis es endlich für Facebook bereit war.
Open Source als Mitwirkende​
In den ersten sechs Monaten des Projekts arbeitete ich Vollzeit daran – und schrieb trotzdem nur die Hälfte der Commits. Das ist an sich schon verblüffend! Nicht nur war der Durchsatz doppelt so hoch, sondern Leute arbeiteten an Dingen, für die ich keine Zeit gehabt hätte: Integrationen mit allen Editoren der Welt, ein Fuzzer zur Fehlersuche, TypeScript-Unterstützung, Infrastruktur für mehrere Sprachen in derselben Datei und mehr.
Obwohl wir nicht alles bei Facebook nutzen, erwiesen sich viele Dinge als nützlich. CSS-in-JS-Unterstützung erleichterte die Formatierung von GraphQL-Fragmenten in Template-Literalen. Die große Nutzerzahl war auch eine gute Methode, um obskure Fehler aufzudecken, die wir irgendwann treffen würden – und viele verschiedene Leute halfen bei der Behebung.
Das Beste: Vor sechs Monaten hörte ich auf, Vollzeit am Projekt zu arbeiten, und es ging weiter unter der Leitung von @azz. Ich möchte allen danken, die auf verschiedene Weise geholfen haben – es ist so aufregend, gemeinsam Geschichte zu schreiben!
Open Source hat Wunder fĂĽr das Projekt bewirkt, brachte Facebook enormen Wert (fast alle unsere JavaScript-Dateien sind jetzt pretty printed) und der gesamten Branche durch die massive Verbreitung.
Werkzeuge: Jest Snapshot-Tests & Playground​
All diese Beiträge waren möglich, weil es einfach war, Fehler zu melden, Code beizutragen und zu prüfen. Die zwei wirkungsvollsten Werkzeuge waren Jest-Snapshot-Tests und der Playground.
Snapshot-Tests sind ein Wunder für einen Pretty-Printer. Neue Tests hinzuzufügen ist denkbar einfach: Erstelle eine Datei im Testordner mit dem zu formatierenden Code, führe Jest aus – voilà ! Bei jeder Änderung siehst du, wie sich Beispiele anders formatieren, und entscheidest, ob es besser ist. Für Prüfer ist der Vorher/Nachher-Vergleich aller Änderungen ideal. Ich achte mittlerweile mehr auf die Snapshots als auf die Implementierung.
Der Playground ist eine großartige Möglichkeit, Repros zu erstellen oder mit Prettier zu experimentieren – ohne Entwicklungsumgebung, richtigen Branch etc. Er erwies sich als extrem wertvoll, um gute, umsetzbare Fehlerberichte zu erhalten.
Höhepunkte​
Unterstützung für Vue Single File Components (#3563) von @vjeux​
Es gibt große Nachfrage nach Vue SFC (#2097). Wir haben teilweise Unterstützung eingeführt: Der gesamte HTML-Code bleibt unverändert, aber jetzt werden <script>- und <style>-Tags mit Prettier formatiert.
Verwende es einfach, indem du prettier auf deinen *.vue-Dateien ausfĂĽhrst!
Prettier Plugin API (#3536) von @azz​
Da Prettier für JavaScript stabil geworden ist, haben wir in letzter Zeit Beiträge von Entwicklern erhalten, die neue Sprachen zu Prettier hinzufügen möchten. Besonders hervorzuheben sind Pull-Requests für Python- und PHP-Unterstützung. Wir wollen das Kernpaket prettier portabel und wartbar halten, gleichzeitig aber Nutzern die Möglichkeit geben, Prettier für weitere Sprachen zu verwenden. Zu diesem Zweck haben wir eine Plugin-API eingeführt! Prettier-Plugins können Parser und/oder Printer für den Prettier-Formatierer bereitstellen. Sie werden als First-Class-Citizens behandelt und können sogar zur Einbettungsunterstützung beitragen (z. B. die Formatierung Ihrer Sprache innerhalb von Markdown).
Die Verwendung von Plugins ist so einfach wie die Installation via npm/yarn und das Ausführen von Prettier wie gewohnt - ohne zusätzliche Konfigurationsaufwand!
Es gibt drei offizielle Plugins in Entwicklung:
Alle drei Plugins befinden sich noch in aktiver Entwicklung und sind nicht fĂĽr Produktionscode geeignet, aber behalten Sie sie im Blick, da sie kontinuierlich weiterentwickelt werden!
Wenn Sie beim Aufbau dieser Plugins helfen möchten, sehen Sie sich die Issue-Listen in deren Repositories an oder testen Sie sie mit Ihrem eigenen Code und melden Sie gefundene Fehler! Ebenso: Wenn Sie eine neue Sprache in Prettier integrieren möchten und Hilfe beim Start benötigen, erstellen Sie ein Issue im prettier-Repo - wir unterstützen Sie gerne.
Prettiers integrierte Sprachen wurden so refaktoriert, dass sie die Plugin-API nutzen, wodurch wir zukünftig garantieren können, dass die Kern-API generisch bleibt.
Weitere Informationen finden Sie in [der Dokumentation][plugin api].
Bitte beachten Sie, dass es sich hier um ein neues, umfangreiches Feature handelt, das wir in der Dokumentation als Beta kennzeichnen. Obwohl wir keine größeren Probleme erwarten, bedeutet dies, dass wir im nächsten Release Breaking Changes vornehmen könnten.
Weitere Änderungen​
TypeScript​
Unterstützung für numerische Trennzeichen (#3580) von @azz​
Numerische Trennzeichen sind ein ECMAScript-Vorschlag der Stufe 3. Die UnterstĂĽtzung wurde in TypeScript 2.7 hinzugefĂĽgt, und Prettier wird sie nun beibehalten.
// 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​
Flow-Typ-Annotationen als Kommentare ausgeben (#3449) von @duailibe​
Flow-Typ-Annotation-Kommentare ermöglichen Typüberprüfung ohne Transpilierung. Vor diesem Release gab Prettier bei Verwendung des Flow-Parsers Typ-Annotationen nicht als Kommentare aus, was diese Funktion unbrauchbar machte. Jetzt erkennt Prettier korrekt, ob eine Typ-Annotation als Kommentar vorlag, und gibt /*: ... */-Kommentare entsprechend aus. Die Unterstützung für /*:: ... */-Kommentare wird aktuell entwickelt.
// Input
let foo: string = "a";
// Before
let foo: string = "a";
// After
let foo: string = "a";
Kommentare nach Pfeilfunktionsparametern ausgeben (#3444) von @duailibe​
Bei Verwendung des Babylon-Parsers gab es verschiedene Probleme mit Flow-Kommentaren, bei denen Kommentare verschoben wurden. Eines davon wurde in diesem Release behoben. Wir kommen der vollständigen Unterstützung dieser Funktion damit näher.
// Before
const run = (cmd /*: string */ /*: Promise<void> */) => {};
// After
const run = (cmd /*: string */) /*: Promise<void> */ => {};
Klammern in FunctionTypeAnnotation ausgeben, wenn arrowParens "always" ist (#3616) von @duailibe​
Im letzten Release fĂĽgten wir die Option arrowParens hinzu. Ein ĂĽbersehener Anwendungsfall waren Flow-Funktionstyp-Annotationen. Nun werden bei Einstellung von arrowParens auf always Klammern um einzelne Argumente gesetzt.
// --arrow-parens always
// Before
type SomeType = {
something: number => number
};
// After
type SomeType = {
something: (number) => number
};
JSX​
Inline-Do-Ausdrücke in JSX (#3607) von @vjeux​
"Do-Ausdrücke" sind ein ECMAScript-Proposal der Stufe 1 und besonders nützlich in JSX. Da die zusätzliche Einrückungsebene nicht erforderlich ist, werden sie nun direkt in den Ausdruckscontainer eingebunden.
// Before
{
do {
// ...
}
}
// After
{do {
// ...
}}
Verhindern von Softline-Zusatz nach Pfeil-Attribut mit Kommentaren (#3641) von @duailibe​
Behebt ein kleines Problem, bei dem zusätzliche Zeilenumbrüche in JSX-Attributen auftraten.
// --print-width 13 (for demonstration)
// Before
<span
attr={
// comment
() =>
true
}
/>;
// After
<span
attr={
// comment
() =>
true
}
/>;
JSX-Elemente in Attributen nicht in () einpacken (#3640) von @duailibe​
Die JSX-Spezifikation erlaubt versteckt die Übergabe von Elementen als Attribute. Prettier fügte fälschlicherweise Klammern hinzu, was Syntaxfehler verursachte. Dieser Release behebt das. Hinweis: Während einige Parser dieses Feature verarbeiten, unterstützen es aktuell keine JSX-Transforms. Als erstes wird Babel 7 (aktuell in Beta) dies ermöglichen.
// Before
<Foo
content=(
<div>
<div />
</div>
)
/>
// After
<Foo
content=<div>
<div />
</div>
/>
SCSS​
Kommentare innerhalb von Selektoren unverändert belassen (#3649) von @vjeux​
Unser CSS-Parser fĂĽr Selektoren unterstĂĽtzt leider keine Kommentare, was dazu fĂĽhrte, dass Kommentare verschoben wurden. Dies wurde nun korrigiert.
/* Before */
// Foo
.foo,
// Bar .bar {
display: block;
}
/* After */
// Foo
.foo,
// Bar
.bar {
display: block;
}
GraphQL​
GraphQL-Parser aktualisiert (#3605) von @vjeux​
Die GraphQL-Spezifikation entwickelt sich weiter. Prettier unterstĂĽtzt nun drei neue Features:
Möglichkeit, Typen mit Textbeschreibungen zu annotieren
"""
Type description
"""
type Foo {
"some description"
someProperty: String!
"""
some really
long description
"""
someOtherProperty: [String!]!
}
Weglassen von {} bei leerem Inhalt
extend enum Site @onEnum
Erweiterbarkeit aller Typen
extend input InputType {
other: Float = 1.23e4
}
Markdown​
Zeilenumbrüche in Multiparsern durch Hardlines ersetzen (#3611) von @ikatyang​
Beim Einbetten von JavaScript in Markdown-Blockzitate wurde das >-Zeichen entfernt. Dies wurde korrigiert.
<!-- before -->
> ````md
> <!-- prettier-ignore -->
> ```js
ugly ( code ) ;
```
> ````
<!-- after -->
> ````md
> <!-- prettier-ignore -->
> ```js
> ugly ( code ) ;
> ```
> ````
Anführungszeichen in Markdown-Linktiteln an singleQuote-Option anpassen (#3481) von @j-f1​
Bisher wurden alle Linktitel in " gesetzt. Nun respektiert Prettier die singleQuote-Option. Bei Titeln mit ' und " werden ()-AnfĂĽhrungszeichen verwendet.
<!-- --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)
Bildreferenzen ohne Alt-Text in Markdown ausgeben (#3643) von @duailibe​
Ein Edge-Case bei Bildreferenzen ohne Alt-Text, der zu AbstĂĽrzen fĂĽhrte, wurde behoben.
<!-- before -->
TypeError: doc is null
<!-- after -->
![][logo]
[logo]: https://github.com/prettier/prettier-logo/blob/master/images/prettier-logo-light.png?raw=true
tabWidth für Listen-Einrückungen berücksichtigen (#3694) von @ikatyang​
Statt fester 2-Leerzeichen-EinrĂĽckungen wird nun tadWidth fĂĽr Listen verwendet.
<!-- --tab-width 4 -->
<!-- before -->
* one
* two
<!-- after -->
* one
* two
API​
options-Feld zu getSupportInfo() hinzugefügt (#3433) von @ikatyang​
prettier.getSupportInfo().options liefert nun ein Array aller unterstĂĽtzten Optionen.
Suche nach .editorconfig nur bis zum VCS-Verzeichnis (#3559) von @josephfrazier​
Um Verwirrung bei unterschiedlichen Formatierungen trotz gleichem Codebase zu vermeiden: Prettier sucht nun .editorconfig-Dateien nur bis zum Projektroot, nicht mehr bis zu ~/.editorconfig.
CLI​
Konsolenausgaben über zentralen Logger (#3515) von @azz​
Die Option --loglevel wurde in einigen Fällen nicht beachtet, jetzt wird sie für alle CLI-Protokollierungen berücksichtigt.
# Before
$ prettier --loglevel silent --write test.js
test.js 91ms
# After
$ prettier --loglevel silent --write test.js
Dateien unverändert ausgeben bei Ignorierung (#3618) von @duailibe​
Wir haben das Verhalten der CLI in Bezug auf ignorierte Dateien korrigiert. Bisher gab die CLI nichts aus, wenn eine Datei durch .prettierignore ignoriert wurde. Dies beeinträchtigte Editor-Integrationen. Das Verhalten ist nun:
-
Bei
--writewird die ignorierte Datei weder gelesen noch beschrieben. -
Ohne
--writewird die ignorierte Datei gelesen und unverändert ausgegeben.
Editor-Integrationen​
PostCSS-Erweiterungen zu getSupportInfo() hinzufügen (#3454) von @ardevelop​
Einige Editor-Integrationen verwenden Prettiers getSupportInfo-Funktion, um alle Sprachen von Prettier dynamisch zu unterstĂĽtzen. Dies fĂĽgt UnterstĂĽtzung fĂĽr *.pcss-Dateien hinzu.
"JSON mit Kommentaren" zu getSupportInfo() hinzufügen (#3496) von @thorn0​
Ebenso wird "JSON mit Kommentaren" nun erkannt.