Por que o TypeScript está no centro de todos os novos aplicativos da web do PayPal?

Publicamos recentemente material em que Eric Elliot criticou o TypeScript. Hoje, chamamos a atenção para a tradução do artigo de Kent Dodds. Aqui ele fala sobre por que o PayPal mudou do Flow para o TypeScript.

Antecedentes

Trabalho no PayPal e estou envolvido na biblioteca de paypal-scripts , que é uma caixa de ferramentas que lembra react-scripts de react-scripts de create-react-app , ou angular-cli ou ember-cli . Eu já escrevi sobre isso. A base desta biblioteca é a ideia de combinar todas as ferramentas usadas nos aplicativos do PayPal e nos módulos publicados. O objetivo de criar paypal-scripts é pegar todas as dependências de desenvolvimento, devDependencies , de package.json , todos os arquivos de configuração e reduzir tudo isso a uma única entrada na seção devDependencies . E, como todas as configurações estão em um único pacote, durante a criação das quais aderem a um ponto de vista muito específico sobre o que é bom, para manter as ferramentas atualizadas, basta atualizar apenas uma dependência (na verdade - paypal-scripts ) , atualizações das quais geralmente não contêm em si mesmas algo que pode atrapalhar a operação do código que depende dele. Como resultado, basta manter uma dependência e envolver-se com calma no desenvolvimento de aplicativos.

No ano passado, os programadores do PayPal estão acostumados a trabalhar com paypal-scripts . Aqui, para criar um novo aplicativo, basta clicar em alguns botões na interface da web, como resultado, um repositório corporativo do GitHub será criado, ferramentas de implantação de projetos, um sistema de integração contínuo e assim por diante. O repositório gerado automaticamente é baseado no repositório de sample-app .

Na semana passada, incluí minha adição, projetada para usar paypal-script nele. Isso significa que no centro de cada novo aplicativo do PayPal haverá uma estrutura construída com base em tecnologias e ferramentas modernas, cuja atualização o desenvolvedor desse aplicativo não precisa se preocupar. Entre outras coisas, esse aplicativo será digitado estaticamente usando TypeScript e testado usando as ferramentas Jest.

Honestamente, este se tornou o Magnum Opus da minha carreira. Eu não achava que um dia conseguiria um nível semelhante no PayPal. Este projeto tem um enorme impacto e sou grato ao PayPal pela oportunidade de trabalhar em algo tão em larga escala.

Então, apresentei o curso, agora vamos falar sobre o TypeScript.

Em meados de dezembro, trabalhei na integração paypal-scripts no sample-app . Também trabalhei (e continuo trabalhando) no pp-react , que é uma biblioteca de componentes (botões, janelas, estilos) adequados para reutilização. Como o paypal-scripts suporta módulos que podem ser publicados, usei o react-scripts para criar o pp-react . Há um mês, a biblioteca de paypal-scripts incluía suporte para o Flow . Foi muito fácil adicionar esse suporte a essa biblioteca graças a Babel.

Em 12 de dezembro, quando eu estava trabalhando no pp-react e na nova versão do sample-app de sample-app em termos de suporte ao Flow, senti que já estava muito cansado do Flow (discutirei isso com mais detalhes abaixo) e tomei uma decisão inesperada. Escrevi uma carta para um colega perguntando como ele olha o que tentarei fazer com que o TypeScript seja usado no sample-app . Ele respondeu: "Sim, faça." Depois, conduzi uma pesquisa no canal #paypal-scripts Slack, que revelou que todos os participantes apóiam minha ideia. Para mim, tudo isso foi suficiente para começar a trabalhar. Cerca de uma semana depois, mudei completamente paypal-scripts do suporte ao Flow para o suporte ao TypeScript. Passamos a maior parte do tempo ensinando todas as ferramentas a reconhecer .ts arquivo .tsx e .tsx e permitindo que o pacote paypal-scripts se teste, o que acabou sendo uma tarefa bastante difícil. Passei vários dias trabalhando no PR no repositório de sample-app , que visava usar a nova biblioteca aprimorada de paypal-scripts e mudar de arquivos .js para .ts e. arquivos tsx . Depois houve feriados e meu PR foi aprovado. Como resultado, agora em cada novo projeto, o PayPal usa digitação estática TypeScript.

Obviamente, depois que alguém cria um novo projeto, ele pode fazer o que quiser com ele. Digamos, você pode excluir todo o código padrão e escrevê-lo no Elm ou em qualquer outra coisa. Isso é completamente normal. Mas os autores da maioria dos projetos aderem às tecnologias usadas para criá-las devido ao chamado " efeito padrão ".

Por que eu fui ao TypeScript por tanto tempo?

A pergunta colocada no título desta seção era frequentemente feita pelos fãs do TypeScript. O fato é que eu conheço há muito tempo o TypeScript, mas meu relacionamento com essa linguagem não se desenvolve há algum tempo. Então, lembro como, por volta de 2013, um colega sugeriu que eu traduzisse código com um volume de cerca de 500 mil linhas no TypeScript. Então, rejeitei esta proposta, mas não me arrependo particularmente, pois naqueles dias o TS era uma linguagem bastante jovem. E uma vez eu entrevistei Anders Halesberg , o criador do TypeScript.

Por isso fiquei longe do TypeScript esse tempo todo.

▍ Razão número 1. Medo de destruir ambientes de trabalho baseados em Babel e ESLint

Para mim, por muito tempo, a principal vantagem do Flow na frente do TypeScript foi que o Flow foi melhor combinado com as ferramentas com as quais estou acostumado. Em particular, uso o Babel e o ESLint há muitos anos com prazer. Gosto de escrever meus próprios plugins para os dois (a propósito, você também pode aprender isso). Gostei do fato de haver grandes comunidades em torno de Babel e ESLint. Como resultado, categoricamente não queria recusá-los. Por uma questão de fato, isso continuou até eventos recentes, pois se eu estivesse planejando deixar o TypeScript com a cabeça, teria que deixar os dois. Obviamente, no mundo do TypeScript existe o TSLint, mas a comunidade ESLint é muito maior.

No Flow, gosto especialmente do fato de que, para incluí-lo no seu fluxo de trabalho, você precisa executar apenas algumas etapas simples:

1. É necessário conectar uma predefinição com suporte para a sintaxe correspondente ao Babel.
2. Você precisa adicionar a construção // @flow ao início de cada arquivo, o tipo de verificação que você deseja organizar (existe um plug-in para ESLint que permite verificar isso).
3. Adicione um script ao projeto que permita executar o Flow para verificar os tipos na base de código.

Eu realmente gosto do fato de que a verificação de tipo (usando Flow) e os projetos de construção (usando Babel, Webpack ou Rollup) são separados. Eu não queria conectar minha vida ao TypeScript, em particular, porque seu compilador, em qualquer caso, não entenderia os plugins para Babel de meu próprio desenvolvimento. E também - devido ao fato de eu ter o Flow - uma ferramenta bastante tolerável.

Agora tudo continua funcionando normalmente. Graças ao Babel 7 (em particular, estamos falando sobre @ babel / preset-typescript ), você pode salvar ferramentas familiares e, além disso, obter a maioria dos recursos do TypeScript à sua disposição. O principal problema é fazer com que as ferramentas aceitem arquivos com extensões. ts e .tsx , mas, felizmente, esse problema está resolvido.

▍ Razão número 2. Os colaboradores terão que aprender TypeScript para contribuir com o projeto.

Falo principalmente sobre código aberto, mas a necessidade do TypeScript ser desenvolvido por quem deseja contribuir com projetos também se aplica ao que faço no trabalho. Ao mesmo tempo, sempre acreditei que os projetos de trabalho deveriam ser digitados, e isso foi alcançado por meio do Flow. Tentei não usar o Flow em meus projetos de código aberto, porque aqueles que decidiram se juntar a eles teriam que aprender o Flow. Eu mesmo sempre falei sobre isso, mas, subconscientemente, sempre citei um contra-argumento, que consiste no fato de que a digitação é, em sua essência, apenas outra forma de teste, mas quem deseja contribuir com o código aberto precisa descobrir. com teste.

Honestamente, a recusa em usar uma certa tecnologia em código aberto apenas porque o colaborador em potencial pode não ser o proprietário me parece uma desculpa ruim para não usar essa tecnologia. E, à medida que mais e mais programadores dominam o TypeScript, acho que depois de um tempo escreverei no TS e em meus projetos de código aberto.

▍ Razão número 3. Poderoso sistema de inferência de tipo de fluxo

Eu li este post e gostei muito. Especialmente sua última linha, segundo a qual ao usar os tipos de fluxo são adicionados para tornar as mensagens de erro mais agradáveis, e não para identificá-las.

Assim é. Atualmente, o Flow tem um sistema de inferência de tipos mais poderoso que o TypeScript, e isso me encorajou.

▍ Razão número 4. Flow, como React, originalmente do Facebook

Pecarei contra a verdade se disser que não sucumbi ao equívoco muito difundido de que acredito que, se uma empresa fez algo grandioso, tudo o que faz será automaticamente no mesmo nível alto. Isso não é de todo garantido. Não tenho mais nada a acrescentar aqui.

▍ Razão número 5. Fanáticos por TypeScript

Acho que todo mundo sabe que, se alguém é realmente fascinado por uma determinada tecnologia, ele, sem parar, conta a todos ao seu redor sobre isso. Alguém está usando o vim aqui ? E os adeptos do TypeScript não são exceção.

A comunidade TypeScript, a propósito, está cheia de ótimas pessoas. Tipo, disposto a ajudar, entusiasmado, amigável. Mas eu também tive que me encontrar com aqueles amantes de TS que chamariam uma pessoa de tola apenas porque ela não usa TypeScript, ou não a entende, ou usa outra coisa. Eles demonstram falta de capacidade de entender o interlocutor e sua posição denuncia esnobismo. Esta não é a comunidade da qual gostaria de fazer parte. Quero dizer, o entusiasmo causado pela tecnologia escolhida por alguém é maravilhoso, mas se for tão longe que um fã dessa tecnologia comece a oprimir quem escolhe outra coisa, já é muito triste .

Eu ainda tenho algumas preocupações sobre isso. Mas espero que juntos tornemos a comunidade TypeScript mais positiva.

Agora que falamos sobre os motivos pelos quais não tenho pressa de mudar para o TypeScript, falarei sobre o que não me agrada no Flow.

Problemas de fluxo

Como eu disse, em algum momento eu estava muito cansado do Flow. Aqui está um dos tweets em que compartilhei um dos principais problemas que encontrei ao trabalhar com o Flow. Consistia no fato de que, para o Flow funcionar, é regularmente necessário, após seu início malsucedido, pará-lo e, em seguida, iniciá-lo novamente. Aqui está outro tweet meu sobre o mau funcionamento do Flow.

Finalmente fui afastado do Flow por problemas regulares com sua confiabilidade. Os plugins para editores funcionavam, por assim dizer, com graus variados de sucesso (devo admitir que não trabalhei com o Nuclide, e talvez, se o tentasse, minha vida teria sido diferente, mas tentei trabalhar com o Flow no Atom e no VSCode), constantemente confrontado com algumas esquisitices. Isso foi muito irritante, pois minou minha fé no sistema de controle de tipo que eu usei.

Quando eu, em novembro, vi esse tweet, ele expressou o que eu já estava pensando; uma pequena história sobre a mudança do Flow para o TypeScript coincidiu com minha visão da situação. Honestamente, eu não conseguia parar de pensar em como lidar adequadamente com o TypeScript. Como resultado, fiz exatamente isso e estou muito feliz com isso.

Perguntas e Respostas

▍ Por que você não está usando o TSLint?

Na verdade, implementei o suporte ao TSLint no paypal-script . Este foi um dos primeiros scripts que ganhei. Eu estava prestes a decidir se deveria usar TSLint ou ESLint com base no fato de o projeto ter um arquivo tsconfig.json . Mas então lembrei que temos alguns plugins ESLint de nosso próprio design (por exemplo, para verificar a internacionalização), que eu não queria perder tempo reescrevendo na forma de plugins para TSLint. Além disso, a interface da linha de comandos do TSLint é menos poderosa que o ESLint e não é adequada para trabalhar com paypal-scripts . Talvez depois de um tempo eu olhe mais de perto o TSLint.

Sim, quero observar que a comunidade ESLint ainda é muito maior que a comunidade TSLint. Além disso, percebo gradualmente que um bom sistema de controle de tipo torna inúteis os plugins de cotão. Enquanto isso, estou usando o TypeScript ESLint, e o que recebo parece muito bom. Aqui está o meu vídeo sobre este tópico.

E, a propósito, tenho a sensação de que a equipe do TypeScript está inclinada para o ESLint, então suponho que fiz a escolha certa.

▍ Por que você não escolheu o motivo?

Em correspondência com este tweet, respondi à oferta de experimentar o TypeScript, dizendo que seria melhor mudar do Flow para o ReasonML. Na verdade, eu sempre falava sobre mudar para o Reason antes de mudar para o TypeScript. Uma das principais razões para tais declarações foi o meu desejo de preservar as ferramentas usuais, sobre as quais eu já falei. Mas, como não precisei desistir de nada, o TypeScript se mostrou mais atraente para mim. Ainda gosto muito do Reason, mas mudar para o Reason significaria uma grande mudança para muitos funcionários do PayPal. E embora eu pense que eles possam lidar com isso, acredito que eles se sentirão mais confortáveis ​​usando o TypeScript do que tentando aprender uma nova linguagem.

Provavelmente, se eu escolhesse Reason, meu PR nunca terminaria no repositório de sample-app . Uma coisa é incentivar os colegas a usar, em essência, o que pode ser chamado de "JavaScript digitado" (especialmente se eles não exigirem suporte para determinadas configurações), e uma conversa completamente diferente ocorrerá se você tentar incentivar os colegas a usar uma linguagem completamente diferente e um ecossistema completamente diferente (e não importa o quão bem essa linguagem interaja com JS e npm).

Sumário

Agora, gostaria de agradecer a todos os usuários do Twitter que influenciaram minha visão do TypeScript. Como eu disse, o fato de a biblioteca de paypal-scripts ter entrado no repositório de sample-app no PayPal é provavelmente a principal conquista da minha carreira. E acredito que o fato de agora os modelos de todos os novos aplicativos da empresa estarem equipados com suporte ao TypeScript por padrão é uma grande vantagem para todos os funcionários do PayPal. Estou imensamente feliz por ter escolhido o TypeScript.

Caros leitores! Você acha que aqueles que usam o Flow devem olhar na direção do TypeScript?