Pourquoi TypeScript est-il au cœur de chaque nouvelle application Web PayPal?

Nous avons récemment publié des documents dans lesquels Eric Elliot critiquait TypeScript. Aujourd'hui, nous portons à votre attention une traduction de l'article de Kent Dodds. Ici, il explique pourquoi PayPal est passé de Flow à TypeScript.

Contexte

Je travaille chez PayPal et je suis impliqué dans la bibliothèque de paypal-scripts , qui est une boîte à outils rappelant les react-scripts de react-scripts de create-react-app , ou angular-cli , ou ember-cli . J'ai déjà écrit à ce sujet. La base de cette bibliothèque est l'idée de combiner tous les outils utilisés dans les applications PayPal et dans les modules publiés. L'objectif de la création paypal-scripts est de prendre toutes les dépendances de développement, devDependencies , de package.json , tous les fichiers de configuration, et de réduire tout cela à une seule entrée dans la section devDependencies . Et, comme toutes les configurations sont dans un seul package, lors de la création desquelles elles adhèrent à un point de vue très précis sur ce qui est bon, pour maintenir les outils à jour, il suffit de mettre à jour une seule dépendance (en fait - paypal-scripts ) , dont les mises à jour ne contiennent généralement pas en elles-mêmes quelque chose qui puisse perturber le fonctionnement du code qui en dépend. En conséquence, il suffit de maintenir une dépendance et de s'engager calmement dans le développement d'applications.

Au cours de la dernière année, les programmeurs PayPal ont l'habitude de travailler avec paypal-scripts . Ici, pour créer une nouvelle application, il suffit de cliquer sur quelques boutons dans l'interface Web, à la suite de quoi un référentiel GitHub d'entreprise sera créé, des outils de déploiement de projet, un système d'intégration continue, etc. seront configurés. Le référentiel généré automatiquement est basé sur le référentiel d' sample-app .

La semaine dernière, il comprenait mon ajout, conçu pour utiliser paypal-script . Cela signifie qu'au cœur de chaque nouvelle application dans PayPal se trouvera un framework construit sur la base de technologies et d'outils modernes, dont la mise à jour n'aura pas à inquiéter le développeur de cette application. Entre autres choses, une telle application sera typée statiquement à l'aide de TypeScript et testée à l'aide des outils Jest.

Honnêtement, c'est devenu le Magnum Opus de ma carrière. Je ne pensais pas qu'un jour je serais en mesure d'atteindre un niveau similaire dans PayPal. Ce projet a un impact énorme, et je suis reconnaissant à PayPal pour l'opportunité de travailler sur quelque chose d'aussi grande échelle.

Donc, je vous ai présenté le cours des choses, parlons maintenant de TypeScript.

À la mi-décembre, j'ai travaillé sur l'intégration paypal-scripts dans l' sample-app . J'ai également travaillé (et continue de travailler) sur le pp-react , qui est une bibliothèque de composants (boutons, fenêtres, styles) pouvant être réutilisés. Puisque paypal-scripts prend en charge les modules qui peuvent être publiés, j'ai utilisé react-scripts pour construire pp-react . Il y a un mois, la bibliothèque de paypal-scripts incluait le support de Flow . Un tel support a été très facile à ajouter à cette bibliothèque grâce à Babel.

Le 12 décembre, alors que je travaillais sur pp-react et la nouvelle version de sample-app en termes de prise en charge de Flow, j'ai senti que j'étais déjà très fatigué de Flow (je vais en discuter plus en détail ci-dessous) et j'ai pris une décision inattendue. J'ai écrit une lettre à un collègue lui demandant comment il regarde ce que j'essaierai de faire utiliser TypeScript dans l' sample-app . Il a répondu: "Oui, faites-le." J'ai ensuite mené une enquête sur la chaîne Slack #paypal-scripts , qui s'est avérée que tous ses participants soutiennent mon idée. Pour moi, tout cela était suffisant pour se mettre au travail. Environ une semaine plus tard, j'ai complètement changé les paypal-scripts du support Flow au support TypeScript. La majeure partie de ce temps a été consacrée à l'enseignement de tous les outils pour reconnaître les .ts fichiers .ts et .tsx , et à permettre au package paypal-scripts de se tester lui-même, ce qui s'est avéré être une tâche assez difficile. Ensuite, j'ai passé plusieurs jours à travailler sur les relations publiques dans le référentiel d' sample-app , qui visait à utiliser la nouvelle bibliothèque de paypal-scripts améliorée et à passer des fichiers .js fichiers .ts et. fichiers tsx . Ensuite, il y a eu des vacances et mon RP a été approuvé. Par conséquent, dans chaque nouveau projet, PayPal utilise désormais le typage TypeScript statique.

Bien sûr, après que quelqu'un a créé un nouveau projet, il peut faire tout ce qu'il veut avec lui. Dites, vous pouvez supprimer tout le code passe-partout et l'écrire sur Elm, ou sur toute autre chose. C'est tout à fait normal. Mais les auteurs de la plupart des projets adhèrent aux technologies qui ont été utilisées pour les créer en raison de ce que l'on appelle «l' effet par défaut ».

Pourquoi suis-je allé à TypeScript depuis si longtemps?

La question posée dans le titre de cette section a souvent été posée par les fans de TypeScript. Le fait est que je connais depuis longtemps TypeScript, mais ma relation avec ce langage ne s'est pas développée depuis un certain temps. Donc, je me souviens comment, vers 2013, un collègue m'a suggéré de traduire du code avec un volume d'environ 500 000 lignes en TypeScript. J'ai ensuite rejeté cette proposition, mais je ne la regrette pas particulièrement, car à l'époque TS était une langue assez jeune. Et une fois, j'ai même interviewé Anders Halesberg , le créateur de TypeScript.

C’est pourquoi je suis resté loin de TypeScript pendant tout ce temps.

▍ Raison numéro 1. Peur de détruire les environnements de travail basés sur Babel et ESLint

Pour moi, pendant très longtemps, le principal avantage de Flow devant TypeScript était que Flow était mieux combiné avec les outils auxquels j'étais habitué. En particulier, j'utilise Babel et ESLint depuis de nombreuses années avec plaisir, j'aime écrire mes propres plugins pour les deux (à propos, vous pouvez également l' apprendre ). J'ai aimé le fait qu'il y avait d'énormes communautés autour de Babel et d'ESLint. En conséquence, je ne voulais catégoriquement pas les refuser. En fait, cela a continué jusqu'aux événements récents, car si je prévoyais de laisser TypeScript avec ma tête, je devrais les quitter tous les deux. Bien sûr, dans le monde TypeScript, il existe une chose telle que TSLint, mais la communauté ESLint est beaucoup plus grande.

Dans Flow, j'aime particulièrement le fait que pour l'inclure dans votre flux de travail, vous ne devez effectuer que quelques étapes simples:

1. Il est nécessaire de connecter un préréglage prenant en charge la syntaxe correspondante à Babel.
2. Vous devez ajouter la construction // @flow au début de chaque fichier, le type de vérification dans lequel vous souhaitez organiser (il existe un plugin pour ESLint qui vous permet de vérifier cela).
3. Ajoutez un script au projet qui vous permet d'exécuter Flow pour vérifier les types dans la base de code.

J'aime vraiment le fait que la vérification de type (en utilisant Flow) et les projets de construction (en utilisant Babel, Webpack ou Rollup) sont séparés. Je ne voulais pas relier ma vie à TypeScript, en particulier, car son compilateur, en tout cas, ne comprendrait pas les plugins pour Babel de mon propre développement. Et aussi - du fait que j'avais Flow - un outil assez tolérable.

Maintenant, tout continue à fonctionner comme d'habitude. Grâce à Babel 7 (en particulier, nous parlons de @ babel / preset-typescript ), vous pouvez enregistrer des outils familiers et, en plus, mettre à votre disposition la plupart des fonctionnalités de TypeScript. Le principal problème est de faire accepter les fichiers avec des extensions par les outils. ts et .tsx , mais, heureusement, ce problème est résolu.

▍ Raison numéro 2. Les contributeurs devront apprendre TypeScript afin de contribuer au projet.

Je parle principalement d'open source, mais le besoin que TypeScript soit développé par ceux qui veulent contribuer à des projets s'applique également à ce que je fais au travail. En même temps, j'ai toujours pensé que les projets de travail devaient être dactylographiés, et cela a été réalisé au moyen de Flow. J'ai essayé de ne pas utiliser Flow dans mes projets open source, car ceux qui décidaient de les rejoindre devaient apprendre Flow. J'ai moi-même toujours parlé de cela, mais, inconsciemment, j'ai toujours cité un contre-argument, qui consiste en ce que la dactylographie n'est, dans son essence, qu'une autre forme de test, mais ceux qui veulent contribuer à l'open source doivent le comprendre avec des tests.

Honnêtement, le refus d'utiliser une certaine technologie dans l'open source juste parce que le contributeur potentiel peut ne pas la posséder me semble une mauvaise excuse pour ne pas utiliser cette technologie. Et, comme de plus en plus de programmeurs maîtrisent TypeScript, je pense que peut-être après un certain temps j'écrirai sur TS et mes projets open source.

▍ Raison numéro 3. Système d'inférence de type à débit puissant

J'ai lu ce post et je l'ai vraiment aimé. Surtout sa dernière ligne, selon laquelle lors de l'utilisation des types de flux sont ajoutés afin de rendre les messages d'erreur plus agréables, et non pour les identifier.

Il en est ainsi. De nos jours, Flow a un système d'inférence de type plus puissant que TypeScript, et cela m'a encouragé.

▍ Raison numéro 4. Flow, comme React, originaire de Facebook

Je vais pécher contre la vérité si je dis que je n'ai pas succombé à l'idée très répandue selon laquelle je crois que si une entreprise a fait quelque chose de grandiose, alors tout ce qu'elle fait sera automatiquement au même niveau élevé. Ce n'est pas du tout garanti. Je n'ai plus rien à ajouter ici.

▍ Raison numéro 5. Fanatiques de TypeScript

Je pense que tout le monde sait que si quelqu'un est vraiment fasciné par une certaine technologie, alors il, sans s'arrêter, en parle à tout le monde autour d'elle. Est-ce que quelqu'un utilise vim ici ? Et les adhérents de TypeScript ne font pas exception.

La communauté TypeScript, en passant, est pleine de gens formidables. Gentil, prêt à aider, enthousiaste, sympathique. Mais j'ai également dû rencontrer de tels amateurs de TS qui qualifieraient une personne d'idiot uniquement parce qu'il n'utilise pas TypeScript, ne le comprend pas ou utilise autre chose. Ils démontrent un manque de capacité à comprendre l'interlocuteur, et leur position trahit le snobisme. Ce n'est pas la communauté dont je voudrais faire partie. Je veux dire, l'enthousiasme provoqué par la technologie choisie par quelqu'un est merveilleux, mais si cela va si loin qu'un fan de cette technologie commence à opprimer ceux qui choisissent autre chose, c'est déjà très triste .

J'ai encore quelques inquiétudes à ce sujet. Mais j'espère qu'ensemble, nous rendrons la communauté TypeScript plus positive.

Maintenant que j'ai parlé des raisons pour lesquelles je n'étais pas pressé de passer à TypeScript, je vais parler de ce qui ne me convient pas dans Flow.

Problèmes de flux

Comme je l'ai dit, à un moment donné, j'étais très fatigué de Flow. Voici l'un des tweets dans lesquels j'ai partagé l'un des principaux problèmes que j'ai rencontrés en travaillant avec Flow. Elle consistait dans le fait que pour que Flow fonctionne, il est régulièrement nécessaire, après un démarrage infructueux, de l'arrêter, puis de le redémarrer. Voici un autre tweet à propos du dysfonctionnement de Flow.

J'ai finalement été repoussé de Flow par des problèmes de fiabilité qui se posaient régulièrement. Les plugins pour les éditeurs ont fonctionné, pour ainsi dire, avec plus ou moins de succès (je dois admettre que je n'ai pas travaillé avec Nuclide, et peut-être que si je l'avais essayé, ma vie aurait été différente, mais j'ai essayé de travailler avec Flow dans Atom et dans VSCode), j'ai constamment face à quelques bizarreries. C'était très ennuyeux car cela minait ma foi dans le système de contrôle de type que j'utilisais.

Lorsque, en novembre, j'ai vu ce tweet, il a exprimé ce à quoi je pensais déjà; une courte histoire sur le passage de Flow à TypeScript a coïncidé avec ma vision de la situation. Honnêtement, je ne pouvais pas m'arrêter de penser à la façon de prendre correctement TypeScript. En conséquence, c'est exactement ce que j'ai fait et j'en suis très heureux.

Q & A

▍ Pourquoi n'utilisez-vous pas TSLint?

En fait, j'ai implémenté le support TSLint dans paypal-script . Ce fut l'un des premiers scripts que j'ai gagné. J'étais sur le point de décider d'utiliser TSLint ou ESLint selon que le projet avait un fichier tsconfig.json . Mais je me suis alors souvenu que nous avions certains plugins ESLint de notre propre conception (par exemple, pour vérifier l'internationalisation), que je ne voulais pas perdre de temps à réécrire en plugins pour TSLint. De plus, l'interface de ligne de commande TSLint est moins puissante que ESLint, et elle n'est pas bien adaptée pour travailler avec paypal-scripts . Peut-être qu'après un certain temps, j'examinerai de plus près TSLint.

Oui, je tiens à noter que la communauté ESLint est encore beaucoup plus grande que la communauté TSLint. De plus, je me rends progressivement compte qu'un bon système de contrôle de type rend les plugins non pelucheux inutiles. En attendant, j'utilise TypeScript ESLint, et ce que j'obtiens semble assez bon. Voici ma vidéo sur ce sujet.

Et en passant, j'ai le sentiment que l'équipe TypeScript penche vers ESLint, donc je suppose que j'ai fait le bon choix.

▍ Pourquoi n'avez-vous pas choisi Reason?

Dans la correspondance sous ce tweet, j'ai répondu à l'offre d'essayer TypeScript, en disant qu'il serait préférable de passer de Flow à ReasonML. En fait, j'ai souvent parlé de passer à Reason avant de passer à TypeScript. L'une des principales raisons de ces déclarations était mon désir de conserver les outils habituels, dont j'ai déjà parlé. Mais comme je n'avais rien à abandonner, TypeScript s'est avéré plus attrayant pour moi. J'aime toujours beaucoup Reason, mais passer à Reason signifierait un énorme changement pour de nombreux employés de PayPal. Et même si je pense qu'ils pourraient le gérer, je pense qu'ils seront plus à l'aise avec TypeScript que d'essayer d'apprendre un nouveau langage.

Probablement, si je choisissais Reason, mon PR ne se retrouverait jamais dans le référentiel d' sample-app . C’est une chose d’encourager ses collègues à utiliser, en substance, ce que l’on peut appeler «JavaScript tapé» (surtout s’ils ne nécessitent pas de prise en charge pour certaines configurations), et une conversation complètement différente aura lieu si vous essayez d’encourager vos collègues à utiliser un langage complètement différent et un écosystème complètement différent (et peu importe à quel point ce langage interagit avec JS et npm).

Résumé

Maintenant, je voudrais remercier tous les utilisateurs de Twitter qui ont influencé ma vision de TypeScript. Comme je l'ai dit, le fait que la bibliothèque de paypal-scripts entrée dans le dépôt d' sample-app de PayPal est probablement la principale réalisation de ma carrière. Et je pense que le fait que les modèles de toutes les nouvelles applications de l'entreprise soient désormais pris en charge par TypeScript par défaut est un énorme avantage pour tous les employés de PayPal. Je suis extrêmement heureux d'avoir choisi TypeScript.

Chers lecteurs! Pensez-vous que ceux qui utilisent Flow devraient regarder dans le sens de TypeScript?