Recientemente publicamos
material en el que Eric Elliot criticó a TypeScript. Hoy traemos a su atención una traducción del artículo de Kent Dodds. Aquí habla sobre por qué PayPal cambió de Flow a TypeScript.
Antecedentes
Trabajo en PayPal y estoy involucrado en la biblioteca de
paypal-scripts , que es una caja de herramientas que recuerda a
react-scripts de
react-scripts de
create-react-app , o
angular-cli , o
ember-cli .
Ya escribí sobre esto. La base de esta biblioteca es la idea de combinar todas las herramientas utilizadas en las aplicaciones de PayPal y en los módulos publicados. El objetivo de crear
paypal-scripts es tomar todas las dependencias de desarrollo,
devDependencies , desde
package.json , todos los archivos de configuración, y reducir todo esto a una sola entrada en la sección
devDependencies . Y, dado que todas las configuraciones están en un solo paquete, durante la creación de las cuales se adhieren a un punto de vista muy específico sobre lo que es bueno, para mantener las herramientas actualizadas, es suficiente para actualizar solo una dependencia (en realidad,
paypal-scripts ) , cuyas actualizaciones generalmente no contienen en sí mismas algo que pueda interrumpir el funcionamiento del código que se basa en él. Como resultado, es suficiente mantener hasta una dependencia y participar tranquilamente en el desarrollo de aplicaciones.
Durante el año pasado, los programadores de PayPal están acostumbrados a trabajar con
paypal-scripts . Aquí, para crear una nueva aplicación, simplemente haga clic en algunos botones en la interfaz web, como resultado de lo cual se creará un repositorio corporativo de GitHub, se configurarán herramientas de implementación de proyectos, un sistema de integración continua, etc. El repositorio generado automáticamente se basa en el repositorio de
sample-app .
La semana pasada, incluyó mi adición, diseñada para usar
paypal-script . Esto significa que en el corazón de cada nueva aplicación en PayPal habrá un marco construido sobre la base de tecnologías y herramientas modernas, cuya actualización no debe preocupar al desarrollador de esta aplicación. Entre otras cosas, dicha aplicación se tipará estáticamente con TypeScript y se probará con las herramientas de Jest.
Honestamente, esto se ha convertido en el Magnum Opus de mi carrera. No pensé que algún día sería capaz de alcanzar un nivel similar en PayPal. Este proyecto tiene un gran impacto, y estoy agradecido a PayPal por la oportunidad de trabajar en algo tan a gran escala.
Entonces, te presenté el curso de las cosas, ahora hablemos sobre TypeScript.
A mediados de diciembre, trabajé en la integración
paypal-scripts en
sample-app . También trabajé (y sigo trabajando) en el
pp-react , que es una biblioteca de componentes (botones, ventanas, estilos) adecuados para su reutilización. Como
paypal-scripts admite módulos que se pueden publicar, utilicé
react-scripts para construir
pp-react . Hace un mes, la biblioteca
paypal-scripts incluía soporte para
Flow . Tal soporte fue muy fácil de agregar a esta biblioteca gracias a Babel.
El 12 de diciembre, cuando estaba trabajando en
pp-react y la nueva versión de
sample-app de
sample-app en términos de soporte de Flow, sentí que ya estaba muy cansado de Flow (lo discutiré con más detalle a continuación) y tomé una decisión inesperada. Escribí una carta a un
colega preguntándole cómo ve lo que intentaré hacer que TypeScript se use en la
sample-app . Él respondió: "Sí, hazlo". Luego realicé una encuesta en el canal Slack
#paypal-scripts , que resultó que todos sus participantes apoyan mi idea. Para mí, todo esto fue suficiente para ponerme a trabajar. Aproximadamente una semana después, cambié completamente
paypal-scripts de
paypal-scripts del soporte de Flow al soporte de TypeScript. La mayor parte de este tiempo se dedicó a enseñar todas las herramientas para reconocer las
.ts archivo
.ts y
.tsx , y a permitir que el paquete
paypal-scripts probara a sí mismo, lo que resultó ser una tarea bastante difícil. Luego pasé varios días trabajando en relaciones públicas en el repositorio de
sample-app , que tenía como objetivo utilizar la nueva biblioteca mejorada
paypal-scripts y cambiar de archivos
.js a
.ts y. archivos
tsx Luego hubo vacaciones, y luego mi RP fue aprobada. Como resultado, ahora en cada nuevo proyecto, PayPal utiliza la escritura estática de TypeScript.
Por supuesto, después de que alguien crea un nuevo proyecto, puede hacer lo que quiera con él. Digamos que puedes eliminar todo el código repetitivo y escribirlo en Elm o en cualquier otra cosa. Esto es completamente normal. Pero los autores de la mayoría de los proyectos se adhieren a las tecnologías que se utilizaron para crearlas debido al llamado "
efecto predeterminado ".
¿Por qué fui a TypeScript durante tanto tiempo?
La pregunta planteada en el título de esta sección a menudo fue hecha por fanáticos de TypeScript. El hecho es que hace tiempo que estoy familiarizado con TypeScript, pero mi relación con este lenguaje no se ha desarrollado durante algún tiempo. Entonces, recuerdo cómo, alrededor de 2013, un colega sugirió que tradujera el código con un volumen de aproximadamente 500 mil líneas a TypeScript. Luego rechacé esta propuesta, pero no me arrepiento particularmente, ya que en aquellos días TS era un lenguaje bastante joven. Y
una vez incluso entrevisté a
Anders Halesberg , el creador de TypeScript.
Por eso me mantuve alejado de TypeScript todo este tiempo.
▍ Razón número 1. Miedo a destruir entornos de trabajo basados en Babel y ESLint
Para mí, durante mucho tiempo, la principal ventaja de Flow frente a TypeScript fue que Flow se combinó mejor con las herramientas a las que estoy acostumbrado. En particular, he estado usando Babel y ESLint durante muchos años con placer, me gusta escribir mis propios complementos para ambos (por cierto, también puedes
aprender esto). Me gustó el hecho de que había grandes comunidades alrededor de Babel y ESLint. Como resultado, categóricamente no quería rechazarlos. De hecho, esto continuó hasta eventos recientes, ya que si planeara dejar TypeScript con mi cabeza, tendría que dejarlos a ambos. Por supuesto, en el mundo de TypeScript existe TSLint, pero la comunidad ESLint es mucho más grande.
En Flow, me gusta especialmente el hecho de que para incluirlo en su flujo de trabajo, debe realizar solo unos pocos pasos simples:
- Es necesario conectar un preset con soporte para la sintaxis correspondiente a Babel.
// @flow agregar la construcción // @flow al comienzo de cada archivo, el tipo de verificación en el que desea organizar (hay un complemento para ESLint que le permite verificar esto).- Agregue un script al proyecto que le permita ejecutar Flow para verificar los tipos en la base del código.
Realmente me gusta el hecho de que la verificación de tipos (usando Flow) y los proyectos de construcción (usando Babel, Webpack o Rollup) están separados. No quería conectar mi vida con TypeScript, en particular, porque su compilador, en cualquier caso, no entendería los complementos para Babel de mi propio desarrollo. Y también, debido al hecho de que tenía Flow, una herramienta bastante tolerable.
Ahora todo sigue funcionando como siempre. Gracias a Babel 7 (en particular, estamos hablando de
@ babel / preset-typescript ), puede guardar herramientas familiares y, además, obtener la mayoría de las características de TypeScript a su disposición. El principal problema es hacer que las herramientas acepten archivos con extensiones.
ts y
.tsx , pero, afortunadamente, este problema está resuelto.
▍ Razón número 2. Los contribuyentes deberán aprender TypeScript para contribuir al proyecto.
Principalmente hablo de código abierto, pero la necesidad de que TypeScript sea desarrollado por aquellos que desean contribuir a proyectos también se aplica a lo que hago en el trabajo. Al mismo tiempo, siempre creí que los proyectos de trabajo deberían ser mecanografiados, y esto se logró por medio de Flow. Traté de no usar Flow en mis proyectos de código abierto, porque aquellos que decidieron unirse a ellos tendrían que aprender Flow. Yo mismo siempre he hablado sobre esto, pero, inconscientemente, siempre he citado un contraargumento, que consiste en el hecho de que escribir es, en esencia, solo otra forma de prueba, pero aquellos que desean contribuir al código abierto tienen que descubrirlo. con pruebas
Honestamente, la negativa a usar cierta tecnología en el código abierto solo porque el contribuyente potencial puede no poseerla me parece una mala excusa para no usar esta tecnología. Y, a medida que más y más programadores dominan TypeScript, creo que después de un tiempo escribiré sobre TS y mis proyectos de código abierto.
▍ Razón número 3. Potente sistema de inferencia de tipo de flujo
Leí
esta publicación y realmente me gustó. Especialmente su última línea, según la cual, al usar Flow, se agregan tipos para hacer que los mensajes de error sean más agradables y no para identificarlos.
Así es En estos días, Flow tiene un sistema de inferencia de tipos más poderoso que TypeScript, y esto me ha animado.
▍ Razón número 4. Flow, como React, originalmente de Facebook
Pecaré contra la verdad si digo que no sucumbí a la idea errónea muy extendida de que creo que si una empresa hizo algo grandioso, entonces todo lo demás que haga estará automáticamente en el mismo nivel alto. Esto no está garantizado en absoluto. No tengo nada más que agregar aquí.
▍ Razón número 5. Fanáticos de TypeScript
Creo que todo el mundo sabe que si alguien está realmente fascinado por cierta tecnología, entonces, sin parar, se lo cuenta a todos a su alrededor. ¿Alguien está usando
vim aquí ? Y los adherentes de TypeScript no son una excepción.
La comunidad de TypeScript, por cierto, está llena de grandes personas. Amable, dispuesto a ayudar, entusiasta, amable. Pero también tuve que reunirme con esos amantes de TS que llamarían tonto a una persona solo porque no usa TypeScript, o no lo entiende, o usa otra cosa. Demuestran una falta de capacidad para entender al interlocutor, y su posición delata el esnobismo. Esta no es la comunidad de la que me gustaría formar parte. Quiero decir, el entusiasmo causado por la tecnología elegida por alguien es maravilloso, pero si llega tan lejos que un fanático de esta tecnología comienza a oprimir a quienes eligen algo más, ya es
muy triste .
Todavía tengo algunas preocupaciones sobre esto. Pero espero que juntos hagamos que la comunidad TypeScript sea más positiva.
Ahora que he hablado sobre las razones por las que no tenía prisa por cambiar a TypeScript, hablaré sobre lo que no me conviene en Flow.
Problemas de flujo
Como dije, en algún momento estaba muy cansado de Flow. Este es uno de los
tweets en los que compartí uno de los principales problemas que encontré al trabajar con Flow. Consistió en el hecho de que, para que Flow funcione, es regularmente necesario, después de su inicio sin éxito, detenerlo y luego volver a iniciarlo. Aquí hay otro
tweet mío sobre el mal funcionamiento de Flow.
Finalmente me alejé de Flow por problemas que surgían regularmente con su confiabilidad. Los complementos para editores funcionaron, por así decirlo, con diversos grados de éxito (debo admitir que no trabajé con Nuclide, y tal vez, si lo intentara, mi vida hubiera resultado diferente, pero intenté trabajar con Flow en Atom y en VSCode), constantemente enfrentado con algunas rarezas. Esto fue muy molesto ya que minó mi fe en el sistema de control de tipos que utilicé.
Cuando, en noviembre, vi
este tweet, él expresó lo que ya estaba pensando; Una breve historia sobre el cambio de Flow a TypeScript coincidió con mi visión de la situación. Honestamente, no podía dejar de pensar en cómo asumir correctamente TypeScript. Como resultado, hice exactamente eso y estoy muy feliz por eso.
Preguntas y respuestas
▍ ¿Por qué no estás usando TSLint?
De hecho, implementé el soporte
TSLint en
paypal-script . Este fue uno de los primeros guiones que obtuve. Estaba a punto de decidir si usar TSLint o ESLint en función de si el proyecto tiene un archivo
tsconfig.json . Pero luego recordé que tenemos algunos complementos de ESLint de nuestro propio diseño (por ejemplo, para verificar la internacionalización), que no quería perder el tiempo reescribiendo en forma de complementos para TSLint. Además, la interfaz de línea de comandos de TSLint es menos potente que ESLint y no es adecuada para trabajar con
paypal-scripts . Quizás después de un tiempo eche un vistazo más de cerca a TSLint.
Sí, quiero señalar que la comunidad ESLint es aún mucho más grande que la comunidad TSLint. Además, gradualmente me doy cuenta de que un buen sistema de control de tipos hace que los complementos de linting sean inútiles. Mientras tanto, estoy usando TypeScript ESLint, y lo que obtengo se ve bastante bien.
Aquí está mi video sobre este tema.
Y, por cierto, tengo la sensación de que el equipo de TypeScript se está inclinando hacia ESLint, así que supongo que tomé la decisión correcta.
▍ ¿Por qué no elegiste Razón?
En correspondencia con
este tweet, respondí a la oferta de probar TypeScript, diciendo que sería mejor cambiar de Flow a ReasonML. De hecho, a menudo hablé sobre cambiar a
Reason antes de cambiar a TypeScript. Una de las principales razones de tales declaraciones fue mi deseo de preservar las herramientas habituales, de las que ya hablé. Pero, como no tenía que renunciar a nada, TypeScript resultó ser más atractivo para mí. Todavía me gusta mucho Reason, pero cambiar a Reason significaría un gran cambio para muchos empleados de PayPal. Y aunque creo que podrían manejarlo, creo que se sentirán más cómodos usando TypeScript que tratando de aprender un nuevo lenguaje.
Probablemente si elijo Reason, mi RP nunca terminaría en el repositorio de
sample-app . Una cosa es alentar a los colegas a usar, en esencia, lo que se puede llamar "JavaScript escrito" (especialmente si no requieren soporte para ciertas configuraciones), y una conversación completamente diferente tendrá lugar si intentas alentar a los colegas a usar un lenguaje completamente diferente y un ecosistema completamente diferente (y no importa qué tan bien interactúe este lenguaje con JS y npm).
Resumen
Ahora, me gustaría
agradecer a todos los usuarios de Twitter que influyeron en mi visión de TypeScript. Como dije, el hecho de que la biblioteca de
paypal-scripts PayPal
sample-app repositorio de
sample-app en PayPal es probablemente el logro principal de mi carrera. Y creo que el hecho de que ahora las plantillas de todas las aplicaciones nuevas de la compañía estén equipadas con soporte TypeScript por defecto es una gran ventaja para todos los empleados de PayPal. Estoy inmensamente contento de haber elegido TypeScript.
Estimados lectores! ¿Crees que aquellos que usan Flow deberían mirar en la dirección de TypeScript?
