Why is TypeScript based on every new web application in PayPal?
We recently published material in which Eric Elliot criticized TypeScript. Today we present to your attention the translation of the article by Kent Dodds. Here he talks about why in PayPal switched from Flow to TypeScript.
I work at PayPal and do the
Over the past year, programmers at PayPal have become accustomed to working with
Just last week, my addition was added to it, calculated on the use of
Honestly, it became the Magnum Opus of my career. I did not think that someday I would be able to reach a similar level in PayPal. This project has a huge impact, and I am grateful to PayPal for giving me the opportunity to work on something so ambitious.
So, I brought you up to date, now let's talk about TypeScript.
In mid-December, I worked to integrate
On December 12, when I was working on
Of course, after someone creates a new project, he can do whatever he wants with him. Say, you can delete all the template code and write it on Elm, or on anything else. This is completely normal. But the authors of most projects adhere to those technologies that were used in their creation due to the so-called “ silence effect ”.
The question in the title of this section was often asked by TypeScript fans. The fact is that I have been familiar with TypeScript for a long time, but I have had a relationship with this language for some time. So, I remember how in about 2013 a colleague suggested that I translate a code of about 500 thousand lines into TypeScript. Then I rejected this offer, but I do not particularly regret it, since at that time TS was a rather young language. And once I even interviewed Anders Hejlsberg , the creator of TypeScript.
That's why I kept out of TypeScript all this time.
For me, for a very long time, the main advantage of Flow in front of TypeScript was that Flow was better combined with the tools I was used to. In particular, I have been using Babel and ESLint for many years, I like to write my own plugins for that and for another (you, too, by the way, can learn this). I liked the fact that there were huge communities around Babel and ESLint. As a result, I categorically did not want to refuse them. As a matter of fact, it lasted until recent events, since if I were going to get into TypeScript, I would have had to leave both. Of course, in the TypeScript world there is such a thing as TSLint, but the ESLint community is much larger.
In Flow, I especially like the fact that in order to include it in my workflow, I need to perform only a few simple steps:
I really like the fact that type checking (using Flow) and building projects (using Babel, Webpack or Rollup) are separate. I did not want to connect my life with TypeScript, in particular, due to the fact that its compiler, in any case, would not understand the Babel plug-ins of my own design. And also - due to the fact that I had Flow - quite a tolerable tool.
Now everything continues to work as usual. Thanks to Babel 7 (in particular, we are talking about @ babel / preset-typescript ), you can save the usual tools and, in addition, get at your disposal most of the capabilities of TypeScript. The main problem is to make the tools accept files with extensions.
I’m talking mainly about open source, but the need to master TypeScript by those who want to contribute to projects also applies to what I do at work. At the same time, I always believed that work projects should be typed, and this was achieved by means of Flow. I tried not to use Flow in my open source projects, because those who decided to join them would have to master Flow. I myself have always talked about this, but, subconsciously, always led a counter-argument, which is that typing is, by its nature, just one more form of testing, and those who want to contribute to the open source still have to understand with testing.
Honestly, the refusal to use some kind of technology in the open source just because the potential contributor may not own it, seems to me a poor excuse for rejecting this technology. And, as more and more programmers master TypeScript, I think that, perhaps, in some time I will write on TS and my own open source projects.
I read this post, and I really liked it. In particular, its last line, according to which when using Flow, types are added in order to make the error messages more pleasant, and not to identify them.
The way it is. Nowadays, Flow has a more powerful type inference system than TypeScript, and this is encouraging.
I will sin against the truth if I say that I did not succumb to a very common misconception, which is to believe that if a certain company did something grandiose, then everything else that it does is automatically at the same high level. This is not at all guaranteed. I have nothing more to add here.
I think everyone knows that if someone is truly fascinated by some kind of technology, then he, without silence, tells everyone around her. Does anyone use vim here ? And TypeScript followers are no exception.
By the way, the TypeScript community is full of great people. Kind, willing to help, full of enthusiasm, friendly. But I had to intersect with such TS lovers who would call a person a fool only because he does not use TypeScript, or does not understand him, or uses something else. They demonstrate a lack of ability to understand the interlocutor, and their position gives snobbery. This is not the community I would like to be a part of. I mean that the enthusiasm caused by the technology chosen by someone is great, but if it goes so far that a fan of this technology starts to oppress those who have chosen something else, it is already very sad .
I still have some concerns about this. But I hope that together we will make the TypeScript community more positive.
Now, when I talked about the reasons why I was in no hurry to switch to TypeScript, I’ll tell you what does not suit me in Flow.
As I said, at a certain point I was very tired of Flow. Here is one of the tweets in which I shared one of the main problems I encountered when working with Flow. It consisted in the fact that in order for Flow to work, it is regularly necessary, after its unsuccessful launch, to stop it, and then start it again. Here's another one of my tweets , where we are talking about the wrong work Flow.
I was finally pushed away from Flow regularly arising problems with its reliability. Plug-ins for editors worked, so to speak, with varying success (I must admit that I did not work with Nuclide, and maybe if I tried it, my life would have been different, but I tried working with Flow in Atom and in VSCode), I constantly faced with some weirdness. This was very annoying, as it undermined my faith in the type control system I used.
When I saw this tweet in November, he expressed what I was already thinking about; A short story about the transition from Flow to TypeScript coincided with my vision of the situation. I honestly could not stop thinking about how to take up TypeScript. In the end, I did it and I'm very happy about it.
In fact, I implemented TSLint support in
Yes, I would like to point out that the ESLint community is still much larger than the TSLint community. In addition, I gradually realize that a good type control system makes the lint plugins useless. In the meantime, I use ESLint with TypeScript, and what turns out looks quite good. Here is my video on this topic.
And by the way, I have a feeling that the TypeScript team is leaning towards ESLint, so I suppose I made the right choice.
I, in correspondence with this tweet, responded to the offer to try TypeScript, saying that it would be better to switch from Flow to ReasonML. In fact, I often talked about switching to Reason before switching to TypeScript. One of the main reasons for such statements was my desire to preserve the usual tools, which I have already mentioned. But, since I didn’t have to give up anything, TypeScript was more attractive to me. I still like Reason very much, but switching to Reason would mean a huge change for many PayPal employees. And although I think they would cope with it, I believe that it will be more comfortable for them to use TypeScript than to try to learn a new language.
Probably, if I chose Reason, my PR would never get into the
Now I would like to thank all Twitter users, under whose influence my vision of TypeScript was formed. As I said, the fact that the
Dear readers! Do you think it is worthwhile for those who use Flow to look towards TypeScript?
Prehistory
I work at PayPal and do the
paypal-scripts library, which is a collection of tools that resembles the react-scripts from create-react-app , or angular-cli , or ember-cli . I already wrote about this. At the core of this library is the idea of combining all the tools used in PayPal applications and in published modules. The purpose of creating paypal-scripts is to take all development dependencies, devDependencies , from package.json , all configuration files, and reduce it all to one entry in the devDependencies section. And, since all configurations are in a single package, during the creation of which they adhere to a quite definite point of view on what is good, in order to keep the tools up to date, it is enough to update only one dependency (actually paypal-scripts ) , updates of which usually do not contain something of such that can disrupt the operation of the code that relies on it. As a result, it is enough to keep only one dependency up to date and calmly develop applications.Over the past year, programmers at PayPal have become accustomed to working with
paypal-scripts . Here, to create a new application, just click on several buttons in the web interface, as a result, a corporate GitHub repository will be created, project deployment tools, a continuous integration system, and so on will be configured. The automatically created repository is based on the sample-app repository.Just last week, my addition was added to it, calculated on the use of
paypal-script in it. This means that each new application in PayPal will be based on a framework built on the basis of modern technologies and tools, the updating of which does not need to be taken care of by the developer of this application. Among other things, such an application will be statically typed using TypeScript and tested using Jest tools.Honestly, it became the Magnum Opus of my career. I did not think that someday I would be able to reach a similar level in PayPal. This project has a huge impact, and I am grateful to PayPal for giving me the opportunity to work on something so ambitious.
So, I brought you up to date, now let's talk about TypeScript.
In mid-December, I worked to integrate
paypal-scripts into sample-app . I also worked (and continue to work) on the pp-react , which is a library of components (buttons, windows, styles) suitable for reuse. Since paypal-scripts supports modules that can be published, I used react-scripts to build pp-react . A month ago, the paypal-scripts library included support for Flow . Such support was very easy to add to this library thanks to Babel.On December 12, when I was working on
pp-react and the new version of the sample-app in terms of supporting Flow, I felt that I was already very tired of Flow (more on this I will tell below) and made an unexpected decision. I wrote a letter to a colleague asking him how he looked at what I would try to do so that TypeScript would be used in the sample-app . He replied: "Yes, do it." Then I arranged a survey on the Slack-channel #paypal-scripts , the results of which turned out that all of its participants support my idea. For me, all this was enough to get to work. About a week later, I completely translated paypal-scripts from Flow support to TypeScript support. Most of this time was spent on teaching all the tools to recognize the .ts and .tsx file .ts , and on allowing the paypal-scripts package to test itself, which turned out to be quite a difficult task. Then I spent a few days working on PR in the sample-app repository, which was aimed at using the new improved paypal-scripts library, and switching from .js files to .ts and. tsx files Then there were holidays, and then my PR was approved. As a result, now in every new project in PayPal static TypeScript typing is used.Of course, after someone creates a new project, he can do whatever he wants with him. Say, you can delete all the template code and write it on Elm, or on anything else. This is completely normal. But the authors of most projects adhere to those technologies that were used in their creation due to the so-called “ silence effect ”.
Why did I go to TypeScript for so long?
The question in the title of this section was often asked by TypeScript fans. The fact is that I have been familiar with TypeScript for a long time, but I have had a relationship with this language for some time. So, I remember how in about 2013 a colleague suggested that I translate a code of about 500 thousand lines into TypeScript. Then I rejected this offer, but I do not particularly regret it, since at that time TS was a rather young language. And once I even interviewed Anders Hejlsberg , the creator of TypeScript.
That's why I kept out of TypeScript all this time.
▍Reason # 1. Fear of destroying the existing working environment based on Babel and ESLint
For me, for a very long time, the main advantage of Flow in front of TypeScript was that Flow was better combined with the tools I was used to. In particular, I have been using Babel and ESLint for many years, I like to write my own plugins for that and for another (you, too, by the way, can learn this). I liked the fact that there were huge communities around Babel and ESLint. As a result, I categorically did not want to refuse them. As a matter of fact, it lasted until recent events, since if I were going to get into TypeScript, I would have had to leave both. Of course, in the TypeScript world there is such a thing as TSLint, but the ESLint community is much larger.
In Flow, I especially like the fact that in order to include it in my workflow, I need to perform only a few simple steps:
- It is necessary to connect to Babel preset with the support of the appropriate syntax.
- It is necessary to add to the beginning of each file, the type check in which you want to organize, the construction of
// @flow(there is a plugin for ESLint that allows you to check it). - Add a script to the project that allows you to run Flow to check types in the code base.
I really like the fact that type checking (using Flow) and building projects (using Babel, Webpack or Rollup) are separate. I did not want to connect my life with TypeScript, in particular, due to the fact that its compiler, in any case, would not understand the Babel plug-ins of my own design. And also - due to the fact that I had Flow - quite a tolerable tool.
Now everything continues to work as usual. Thanks to Babel 7 (in particular, we are talking about @ babel / preset-typescript ), you can save the usual tools and, in addition, get at your disposal most of the capabilities of TypeScript. The main problem is to make the tools accept files with extensions.
ts and .tsx , but, fortunately, this problem is solved.▍Reason # 2. Contributors will have to learn TypeScript in order to contribute to the project.
I’m talking mainly about open source, but the need to master TypeScript by those who want to contribute to projects also applies to what I do at work. At the same time, I always believed that work projects should be typed, and this was achieved by means of Flow. I tried not to use Flow in my open source projects, because those who decided to join them would have to master Flow. I myself have always talked about this, but, subconsciously, always led a counter-argument, which is that typing is, by its nature, just one more form of testing, and those who want to contribute to the open source still have to understand with testing.
Honestly, the refusal to use some kind of technology in the open source just because the potential contributor may not own it, seems to me a poor excuse for rejecting this technology. And, as more and more programmers master TypeScript, I think that, perhaps, in some time I will write on TS and my own open source projects.
▍Reason number 3. Powerful output type flow
I read this post, and I really liked it. In particular, its last line, according to which when using Flow, types are added in order to make the error messages more pleasant, and not to identify them.
The way it is. Nowadays, Flow has a more powerful type inference system than TypeScript, and this is encouraging.
▍Reason # 4. Flow, like React, comes from Facebook
I will sin against the truth if I say that I did not succumb to a very common misconception, which is to believe that if a certain company did something grandiose, then everything else that it does is automatically at the same high level. This is not at all guaranteed. I have nothing more to add here.
▍Price number 5. Big fanatics for TypeScript
I think everyone knows that if someone is truly fascinated by some kind of technology, then he, without silence, tells everyone around her. Does anyone use vim here ? And TypeScript followers are no exception.
By the way, the TypeScript community is full of great people. Kind, willing to help, full of enthusiasm, friendly. But I had to intersect with such TS lovers who would call a person a fool only because he does not use TypeScript, or does not understand him, or uses something else. They demonstrate a lack of ability to understand the interlocutor, and their position gives snobbery. This is not the community I would like to be a part of. I mean that the enthusiasm caused by the technology chosen by someone is great, but if it goes so far that a fan of this technology starts to oppress those who have chosen something else, it is already very sad .
I still have some concerns about this. But I hope that together we will make the TypeScript community more positive.
Now, when I talked about the reasons why I was in no hurry to switch to TypeScript, I’ll tell you what does not suit me in Flow.
Flow problems
As I said, at a certain point I was very tired of Flow. Here is one of the tweets in which I shared one of the main problems I encountered when working with Flow. It consisted in the fact that in order for Flow to work, it is regularly necessary, after its unsuccessful launch, to stop it, and then start it again. Here's another one of my tweets , where we are talking about the wrong work Flow.
I was finally pushed away from Flow regularly arising problems with its reliability. Plug-ins for editors worked, so to speak, with varying success (I must admit that I did not work with Nuclide, and maybe if I tried it, my life would have been different, but I tried working with Flow in Atom and in VSCode), I constantly faced with some weirdness. This was very annoying, as it undermined my faith in the type control system I used.
When I saw this tweet in November, he expressed what I was already thinking about; A short story about the transition from Flow to TypeScript coincided with my vision of the situation. I honestly could not stop thinking about how to take up TypeScript. In the end, I did it and I'm very happy about it.
Questions and answers
▍Why don't you use TSLint?
In fact, I implemented TSLint support in
paypal-script . It was one of the first scripts that I earned. I was going to decide whether to use TSLint or ESLint based on whether there is a tsconfig.json file in the project. But then I remembered that we have some own-designed ESLint plug-ins (for example, to check internationalization), which I did not want to waste time rewriting in the form of plug-ins for TSLint. In addition, the TSLint command line interface has fewer features than ESLint, and it is not well suited for working with paypal-scripts . Maybe after a while I will again look at TSLint.Yes, I would like to point out that the ESLint community is still much larger than the TSLint community. In addition, I gradually realize that a good type control system makes the lint plugins useless. In the meantime, I use ESLint with TypeScript, and what turns out looks quite good. Here is my video on this topic.
And by the way, I have a feeling that the TypeScript team is leaning towards ESLint, so I suppose I made the right choice.
▍Why didn’t you choose Reason?
I, in correspondence with this tweet, responded to the offer to try TypeScript, saying that it would be better to switch from Flow to ReasonML. In fact, I often talked about switching to Reason before switching to TypeScript. One of the main reasons for such statements was my desire to preserve the usual tools, which I have already mentioned. But, since I didn’t have to give up anything, TypeScript was more attractive to me. I still like Reason very much, but switching to Reason would mean a huge change for many PayPal employees. And although I think they would cope with it, I believe that it will be more comfortable for them to use TypeScript than to try to learn a new language.
Probably, if I chose Reason, my PR would never get into the
sample-app repository. One thing is to encourage colleagues to use, in essence, what can be called “typed JavaScript” (especially if they do not need support for certain configurations), and a completely different conversation will take place if you try to encourage colleagues to use a completely different language and a completely different ecosystem (and it doesn’t matter how well this language interacts with JS and npm).Results
Now I would like to thank all Twitter users, under whose influence my vision of TypeScript was formed. As I said, the fact that the
paypal-scripts library got into the sample-app repository in PayPal is probably the main achievement of my career. And I think that the fact that now all new application templates in the company are equipped with TypeScript support by default is a huge plus for all PayPal employees. I am immensely pleased that I have chosen TypeScript.Dear readers! Do you think it is worthwhile for those who use Flow to look towards TypeScript?
Source: https://habr.com/ru/post/437986/