Warum ist TypeScript das Herzstück jeder neuen PayPal-Webanwendung?

Wir haben kürzlich Material veröffentlicht , in dem Eric Elliot TypeScript kritisiert hat. Heute machen wir Sie auf eine Übersetzung des Artikels von Kent Dodds aufmerksam. Hier spricht er darüber, warum PayPal von Flow zu TypeScript gewechselt ist.

Hintergrund

Ich arbeite bei PayPal und bin an der paypal-scripts Bibliothek beteiligt, einer Toolbox, die an react-scripts aus der create-react-app oder angular-cli oder ember-cli . Ich habe bereits darüber geschrieben . Grundlage dieser Bibliothek ist die Idee, alle in PayPal-Anwendungen und in veröffentlichten Modulen verwendeten Tools zu kombinieren. Das Ziel beim Erstellen von paypal-scripts besteht darin, alle Entwicklungsabhängigkeiten, devDependencies , aus package.json und alle Konfigurationsdateien zu übernehmen und all dies auf einen einzigen Eintrag im Abschnitt devDependencies . Und da sich alle Konfigurationen in einem einzigen Paket befinden, bei dessen Erstellung sie sich an einen ganz bestimmten Standpunkt halten, um die Tools auf dem neuesten Stand zu halten, reicht es aus, nur eine Abhängigkeit zu aktualisieren (tatsächlich - paypal-scripts ). , deren Aktualisierungen normalerweise nichts enthalten, was den Betrieb des darauf basierenden Codes stören kann. Infolgedessen reicht es aus, eine Abhängigkeit aufrechtzuerhalten und sich ruhig an der Anwendungsentwicklung zu beteiligen.

Im vergangenen Jahr waren PayPal-Programmierer daran paypal-scripts , mit paypal-scripts . Um hier eine neue Anwendung zu erstellen, klicken Sie einfach auf einige Schaltflächen in der Weboberfläche, wodurch ein GitHub-Unternehmensrepository erstellt, Projektbereitstellungstools, ein kontinuierliches Integrationssystem usw. konfiguriert werden. Das automatisch generierte Repository basiert auf dem sample-app Repository.

Erst letzte Woche enthielt es meinen Zusatz, der für die Verwendung von paypal-script wurde. Dies bedeutet, dass das Herzstück jeder neuen Anwendung in PayPal ein Framework sein wird, das auf modernen Technologien und Tools basiert, über deren Aktualisierung sich der Entwickler dieser Anwendung nicht Gedanken machen muss. Unter anderem wird eine solche Anwendung mit TypeScript statisch typisiert und mit Jest-Tools getestet.

Ehrlich gesagt ist dies das Magnum Opus meiner Karriere geworden. Ich hätte nicht gedacht, dass ich eines Tages in PayPal ein ähnliches Niveau erreichen könnte. Dieses Projekt hat enorme Auswirkungen, und ich bin PayPal für die Gelegenheit dankbar, an etwas so Großem zu arbeiten.

Also habe ich Sie in den Verlauf der Dinge eingeführt. Lassen Sie uns nun über TypeScript sprechen.

Mitte Dezember habe ich daran gearbeitet, paypal-scripts in die sample-app . Ich habe auch an dem pp-react gearbeitet (und arbeite weiter daran), einer Bibliothek von Komponenten (Schaltflächen, Fenster, Stile), die zur Wiederverwendung geeignet sind. Da paypal-scripts Module unterstützen, die veröffentlicht werden können, habe ich react-scripts , um pp-react zu erstellen. Vor einem Monat enthielt die paypal-scripts Bibliothek Unterstützung für Flow . Diese Unterstützung konnte dank Babel sehr einfach zu dieser Bibliothek hinzugefügt werden.

Als ich am 12. Dezember an pp-react und der neuen Version der sample-app im Hinblick auf die Flow-Unterstützung arbeitete, hatte ich das Gefühl, dass ich Flow bereits sehr satt hatte (ich werde dies weiter unten ausführlicher besprechen) und traf eine unerwartete Entscheidung. Ich schrieb einen Brief an einen Kollegen und fragte ihn, wie er sieht, was ich versuchen werde, TypeScript in der sample-app . Er antwortete: "Ja, mach es." Dann führte ich eine Umfrage auf dem Slack-Kanal #paypal-scripts , bei der sich herausstellte, dass alle Teilnehmer meine Idee unterstützen. Für mich war das alles genug, um an die Arbeit zu gehen. Ungefähr eine Woche später habe ich paypal-scripts vollständig von der Flow-Unterstützung auf die TypeScript-Unterstützung umgestellt. Die meiste Zeit wurde damit verbracht, alle Tools zum Erkennen von .ts und .tsx Dateierweiterungen zu unterrichten und das paypal-scripts Paket selbst testen zu lassen, was sich als ziemlich schwierige Aufgabe herausstellte. Dann habe ich mehrere Tage an PR im sample-app Repository gearbeitet, das darauf abzielte, die neue verbesserte paypal-scripts .js paypal-scripts Bibliothek zu verwenden und von .js Dateien zu .ts und zu wechseln. tsx Dateien. Dann gab es Feiertage, und dann wurde meine PR genehmigt. Daher verwendet PayPal jetzt in jedem neuen Projekt die statische TypeScript-Typisierung.

Nachdem jemand ein neues Projekt erstellt hat, kann er natürlich mit ihm machen, was er will. Angenommen, Sie können den gesamten Boilerplate-Code löschen und auf Elm oder auf etwas anderes schreiben. Das ist völlig normal. Die Autoren der meisten Projekte halten sich jedoch aufgrund des sogenannten „ Standardeffekts “ an die Technologien, mit denen sie erstellt wurden.

Warum bin ich so lange zu TypeScript gegangen?

Die im Titel dieses Abschnitts gestellte Frage wurde häufig von TypeScript-Fans gestellt. Tatsache ist, dass ich mit TypeScript schon lange vertraut bin, aber meine Beziehung zu dieser Sprache hat sich seit einiger Zeit nicht entwickelt. Ich erinnere mich also, wie ein Kollege um 2013 vorschlug, Code mit einem Volumen von etwa 500.000 Zeilen in TypeScript zu übersetzen. Dann habe ich diesen Vorschlag abgelehnt, aber ich bereue es nicht besonders, da TS damals eine ziemlich junge Sprache war. Und einmal habe ich sogar Anders Halesberg , den Schöpfer von TypeScript, interviewt.

Deshalb habe ich mich die ganze Zeit von TypeScript ferngehalten.

▍ Grund Nummer 1. Angst vor der Zerstörung von Babel- und ESLint-basierten Arbeitsumgebungen

Für mich war der Hauptvorteil von Flow vor TypeScript sehr lange, dass Flow besser mit den Tools kombiniert wurde, die ich gewohnt bin. Insbesondere benutze ich Babel und ESLint seit vielen Jahren mit Vergnügen. Ich schreibe gerne meine eigenen Plugins für beide (das können Sie übrigens auch lernen ). Ich mochte die Tatsache, dass es um Babel und ESLint riesige Communities gab. Infolgedessen wollte ich sie kategorisch nicht ablehnen. Tatsächlich dauerte dies bis zu den jüngsten Ereignissen, denn wenn ich TypeScript mit meinem Kopf verlassen wollte, musste ich beide verlassen. Natürlich gibt es in der TypeScript-Welt so etwas wie TSLint, aber die ESLint-Community ist viel größer.

In Flow gefällt mir besonders die Tatsache, dass Sie nur wenige einfache Schritte ausführen müssen, um es in Ihren Workflow aufzunehmen:

1. Es ist erforderlich, ein Preset mit Unterstützung für die entsprechende Syntax mit Babel zu verbinden.
2. Sie müssen das Konstrukt // @flow am Anfang jeder Datei hinzufügen, die Typprüfung, die Sie organisieren möchten (es gibt ein Plug-In für ESLint, mit dem Sie dies überprüfen können).
3. Fügen Sie dem Projekt ein Skript hinzu, mit dem Sie Flow ausführen können, um die Typen in der Codebasis zu überprüfen.

Ich mag die Tatsache sehr, dass Typprüfung (mit Flow) und Bauprojekte (mit Babel, Webpack oder Rollup) getrennt sind. Ich wollte mein Leben nicht mit TypeScript verbinden, insbesondere weil sein Compiler auf jeden Fall die Plugins für Babel meiner eigenen Entwicklung nicht verstehen würde. Und auch - aufgrund der Tatsache, dass ich Flow hatte - ein ziemlich erträgliches Werkzeug.

Jetzt funktioniert alles wie gewohnt weiter. Dank Babel 7 (insbesondere geht es um @ babel / preset-typescript ) können Sie vertraute Tools speichern und außerdem die meisten Funktionen von TypeScript zur Verfügung stellen. Das Hauptproblem besteht darin, dass die Tools Dateien mit Erweiterungen akzeptieren. ts und .tsx , aber zum Glück ist dieses Problem gelöst.

▍ Grund Nummer 2. Mitwirkende müssen TypeScript lernen, um zum Projekt beizutragen.

Ich spreche hauptsächlich über Open Source, aber die Notwendigkeit, TypeScript von jenen zu entwickeln, die zu Projekten beitragen möchten, gilt auch für meine Arbeit. Gleichzeitig war ich immer der Meinung, dass Arbeitsprojekte getippt werden sollten, und dies wurde mittels Flow erreicht. Ich habe versucht, Flow in meinen Open Source-Projekten nicht zu verwenden, da diejenigen, die sich für eine Teilnahme entschieden haben, Flow lernen müssten. Ich selbst habe immer darüber gesprochen, aber unbewusst habe ich immer ein Gegenargument zitiert, das darin besteht, dass das Tippen im Wesentlichen nur eine andere Form des Testens ist, aber diejenigen, die zu Open Source beitragen wollen, müssen es herausfinden mit testen.

Ehrlich gesagt scheint mir die Weigerung, eine bestimmte Technologie in Open Source zu verwenden, nur weil der potenzielle Mitwirkende sie möglicherweise nicht besitzt, eine schlechte Entschuldigung dafür zu sein, diese Technologie nicht zu verwenden. Und da immer mehr Programmierer TypeScript beherrschen, denke ich, dass ich vielleicht nach einer Weile über TS und meine Open Source-Projekte schreiben werde.

▍ Grund Nummer 3. Leistungsstarkes Inferenzsystem für Strömungstypen

Ich habe diesen Beitrag gelesen und er hat mir sehr gut gefallen. Insbesondere die letzte Zeile, nach der bei Verwendung von Flow-Typen hinzugefügt wird, um Fehlermeldungen angenehmer zu gestalten und nicht um sie zu identifizieren.

So ist es. Heutzutage verfügt Flow über ein leistungsfähigeres Typinferenzsystem als TypeScript, was mich ermutigt hat.

▍ Grund Nummer 4. Flow, wie React, ursprünglich von Facebook

Ich werde gegen die Wahrheit sündigen, wenn ich sage, dass ich nicht dem weit verbreiteten Missverständnis erlegen bin, dass alles andere, was es tut, automatisch auf dem gleichen hohen Niveau sein wird, wenn ein Unternehmen etwas Großartiges getan hat. Dies ist überhaupt nicht garantiert. Ich habe hier nichts mehr hinzuzufügen.

▍ Grund Nummer 5. TypeScript-Fanatiker

Ich denke, jeder weiß, dass wenn jemand wirklich von einer bestimmten Technologie fasziniert ist, er, ohne anzuhalten, allen um sie herum davon erzählt. Verwendet hier jemand vim ? Und TypeScript-Anhänger sind keine Ausnahme.

Die TypeScript-Community ist übrigens voller großartiger Leute. Freundlich, hilfsbereit, enthusiastisch, freundlich. Aber ich musste mich mit solchen TS-Liebhabern treffen, die eine Person nur deshalb als Narren bezeichnen würden, weil sie TypeScript nicht verwendet oder es nicht versteht oder etwas anderes verwendet. Sie zeigen einen Mangel an Fähigkeit, den Gesprächspartner zu verstehen, und ihre Position verrät Snobismus. Dies ist nicht die Community, zu der ich gerne gehören würde. Ich meine, die Begeisterung, die durch die von jemandem gewählte Technologie verursacht wird, ist wunderbar, aber wenn es so weit geht, dass ein Fan dieser Technologie anfängt, diejenigen zu unterdrücken, die sich für etwas anderes entscheiden, ist es bereits sehr traurig .

Ich habe immer noch Bedenken. Ich hoffe jedoch, dass wir gemeinsam die TypeScript-Community positiver gestalten.

Nachdem ich über die Gründe gesprochen habe, warum ich es nicht eilig hatte, zu TypeScript zu wechseln, werde ich darüber sprechen, was in Flow nicht zu mir passt.

Flow-Probleme

Wie gesagt, irgendwann hatte ich Flow sehr satt. Hier ist einer der Tweets, in denen ich eines der Hauptprobleme geteilt habe, auf die ich bei der Arbeit mit Flow gestoßen bin. Es bestand darin, dass Flow nach seinem erfolglosen Start regelmäßig gestoppt und dann erneut gestartet werden muss, damit Flow funktioniert. Hier ist ein weiterer Tweet von mir über die Fehlfunktion von Flow.

Ich wurde schließlich von Flow verdrängt, weil regelmäßig Probleme mit seiner Zuverlässigkeit auftraten. Plugins für Redakteure funktionierten sozusagen mit unterschiedlichem Erfolg (ich muss zugeben, dass ich nicht mit Nuclide gearbeitet habe, und wenn ich es versucht hätte, wäre mein Leben vielleicht anders verlaufen, aber ich habe versucht, mit Flow in Atom und in VSCode zu arbeiten), habe ich ständig gearbeitet mit einigen Kuriositäten konfrontiert. Dies war sehr ärgerlich, da es mein Vertrauen in das von mir verwendete Typsteuerungssystem untergrub.

Als ich im November diesen Tweet sah, drückte er aus, woran ich bereits dachte; Eine Kurzgeschichte über den Wechsel von Flow zu TypeScript fiel mit meiner Vision der Situation zusammen. Ehrlich gesagt konnte ich nicht aufhören darüber nachzudenken, wie man TypeScript richtig aufnimmt. Infolgedessen habe ich genau das getan und bin sehr glücklich darüber.

Fragen und Antworten

▍ Warum verwenden Sie TSLint nicht?

Tatsächlich habe ich die TSLint- Unterstützung in paypal-script implementiert. Dies war eines der ersten Skripte, die ich verdient habe. Ich wollte gerade entscheiden, ob ich TSLint oder ESLint verwenden soll, basierend darauf, ob das Projekt eine tsconfig.json Datei hat. Aber dann erinnerte ich mich, dass wir einige ESLint-Plugins unseres eigenen Designs hatten (zum Beispiel um die Internationalisierung zu überprüfen), die ich nicht als Plugins für TSLint umschreiben wollte. Darüber hinaus ist die TSLint-Befehlszeilenschnittstelle weniger leistungsfähig als ESLint und eignet sich nicht für die Arbeit mit paypal-scripts . Vielleicht werde ich mir TSLint nach einer Weile genauer ansehen.

Ja, ich möchte darauf hinweisen, dass die ESLint-Community immer noch viel größer ist als die TSLint-Community. Außerdem wird mir allmählich klar, dass ein gutes Typsteuerungssystem Flusen-Plugins unbrauchbar macht. In der Zwischenzeit verwende ich TypeScript ESLint und was ich bekomme, sieht ziemlich gut aus. Hier ist mein Video zu diesem Thema.

Übrigens habe ich das Gefühl, dass sich das TypeScript-Team zu ESLint neigt, also habe ich wohl die richtige Wahl getroffen.

▍ Warum hast du dich nicht für Grund entschieden?

In der Korrespondenz unter diesem Tweet antwortete ich auf das Angebot, TypeScript auszuprobieren, und sagte, es sei besser, von Flow zu ReasonML zu wechseln. Tatsächlich habe ich oft über den Wechsel zu Reason gesprochen, bevor ich zu TypeScript gewechselt bin. Einer der Hauptgründe für solche Aussagen war mein Wunsch, die üblichen Werkzeuge zu erhalten, über die ich bereits gesprochen habe. Da ich jedoch nichts aufgeben musste, erwies sich TypeScript für mich als attraktiver. Ich mag Reason immer noch sehr, aber ein Wechsel zu Reason würde für viele PayPal-Mitarbeiter eine große Veränderung bedeuten. Und obwohl ich denke, dass sie damit umgehen können, glaube ich, dass sie mit TypeScript besser umgehen können als mit dem Versuch, eine neue Sprache zu lernen.

Wenn ich mich für Reason entscheiden würde, würde meine PR wahrscheinlich nie im sample-app Repository landen. Es ist eine Sache, Kollegen zu ermutigen, im Wesentlichen das zu verwenden, was als "typisiertes JavaScript" bezeichnet werden kann (insbesondere, wenn sie für bestimmte Konfigurationen keine Unterstützung benötigen). Wenn Sie versuchen, Kollegen zur Verwendung zu ermutigen, findet eine völlig andere Konversation statt eine völlig andere Sprache und ein völlig anderes Ökosystem (und es spielt keine Rolle, wie gut diese Sprache mit JS und npm interagiert).

Zusammenfassung

Jetzt möchte ich mich bei allen Twitter-Nutzern bedanken , die meine Vision von TypeScript beeinflusst haben. Wie gesagt, die Tatsache, dass die paypal-scripts in das sample-app Repository von PayPal aufgenommen wurde, ist wahrscheinlich der wichtigste Erfolg meiner Karriere. Und ich glaube, dass die Tatsache, dass die Vorlagen aller neuen Anwendungen im Unternehmen standardmäßig mit TypeScript-Unterstützung ausgestattet sind, ein großes Plus für alle PayPal-Mitarbeiter ist. Ich bin sehr froh, dass ich mich für TypeScript entschieden habe.

Liebe Leser! Denken Sie, dass diejenigen, die Flow verwenden, in Richtung TypeScript schauen sollten?