Comienza a Construir tus Propias Herramientas de JavaScript

[♪ música ♪ de The Illuminati suena)] [♪ música ♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ de The Illuminati suena♪ te mostraré cómo. ¿Qué tal si pudiéramos comenzar a construir nuestras propias herramientas? ¿Por dónde empezaríamos? ¿Y si las herramientas fueran específicas para nuestro proyecto? Únicas y útiles, adaptadas a nuestras necesidades? ¿Y si pudiéramos aprender cómo hacer esto en los próximos 20 minutos, aprendiendo lo que necesitamos saber y cómo dar nuestros primeros pasos? En los próximos 20 minutos, escribamos nuestra primera regla de impresión, escribamos nuestro primer código mod, veamos nuestro primer AST y construyamos nuestra comprensión de ellos, y aprendamos los fundamentos de cómo funcionan nuestras herramientas. Comencemos.

Veo un hilo común en cualquier proyecto en el que trabajo. Diferentes desarrolladores cometen el mismo error y tenemos formas preferidas de hacer las cosas aunque es difícil comunicarlo a todos los demás en nuestro proyecto o que usan nuestra biblioteca. Prevenir errores y compartir mejores prácticas son excelentes razones para considerar herramientas como linters y en particular ESLint. No solo podemos usar las reglas existentes de ESLint para manejar muchos problemas, sino que tiene un rico ecosistema de complementos específicos para diferentes áreas y podemos escribir nuestras propias reglas y complementos, lo cual te mostraré cómo hacerlo. Las reglas de ESLint son excelentes para problemas o errores que siguen surgiendo, creando un mejor ciclo de retroalimentación para los desarrolladores mientras escriben su código, automatizando la retroalimentación de la revisión de código, compartiendo mejores prácticas y previniendo anti-patrones en nuestras bases de código. Las reglas pueden ser para cualquier proyecto, tal vez solo para tu aplicación, ayudando a los desarrolladores en tu equipo inmediato u otros en una base de código compartida. Si mantienes una biblioteca, pueden ayudar a cualquier persona que use tu biblioteca. Cualquiera puede escribir estas reglas, no solo los mantenedores del proyecto o los desarrolladores expertos.

Muy bien, escribamos nuestra primera regla juntos. Voy a compartir un poco sobre en qué trabajo y un problema que me gusta resolver y que creo que sería realmente útil. En este momento, trabajo en un sistema de diseño llamado Canvas y proporcionamos una biblioteca de componentes para que los desarrolladores de UI la utilicen. Invertimos mucho en hacer que nuestros componentes sean accesibles y útiles en una amplia gama de casos de uso. Como parte de ese esfuerzo, mantenemos tres paquetes diferentes para nuestros componentes, principal, vista previa y laboratorios. Por lo general, construimos nuevos componentes en laboratorios o vista previa, y a medida que probamos la API, refinamos diseño y nos aseguramos de que la accesibilidad esté perfeccionada, promovemos las cosas de laboratorios y vista previa a principal. Sin embargo, esto presenta un desafío algo único. Tenemos algunos componentes antiguos, generalmente en principal, que serán reemplazados por versiones más nuevas en laboratorios o vista previa. Cuando un desarrollador está eligiendo entre las dos versiones, ¿por cuál se decide? A veces, realmente queremos decirles a los desarrolladores que usen la versión más nueva en laboratorios o vista previa. Ya planeamos promoverlo a principal en una próxima versión. El componente está listo para usar y tiene algunos beneficios que no queremos que nuestros usuarios se pierdan en. ¿Cómo comunicamos esto? Hacemos lo que podemos con nuestra documentación y enviando anuncios, pero la mejor manera es decírselo mientras escriben su código. Estoy abriendo una herramienta en línea que uso para probar nuevas reglas. Por lo general, desarrollo con un conjunto de pruebas escribiendo, las reglas de Lint son un caso de uso realmente bueno para el desarrollo impulsado por pruebas. Esta herramienta es excelente para explorar el problema, obtener un primer borrador y a menudo eso es suficiente. Esto es astexplorer.net. Aquí hay algunas cosas sucediendo, pero explicaré cómo funciona cada parte. A la izquierda, hay dos editores colocados para el código en el que estamos trabajando en la parte superior izquierda y un editor para escribir una regla de AS Lint debajo y otras herramientas también. A la derecha, tenemos un visor de AST arriba y una ventana de salida para depurar debajo de eso.

En el encabezado, también podemos configurar el analizador y el tipo de transformación, que ya he establecido en el analizador Babel AS Lint y AS Lint v8. Además de brindarnos un entorno de desarrollo realmente útil, este visor de AST en la parte superior derecha es increíble y lo exploraremos en un momento.

AST es un acrónimo de abstract syntax tree (árbol de sintaxis abstracta). Si no estudiaste ciencias de la computación en la universidad, la terminología para un AST puede parecer intimidante. Pero te prometo que es solo un árbol y si has trabajado con un DOM para una página web, sabes cómo funciona un árbol. Un AST simplemente almacena la sintaxis de nuestro código. Podemos explorar este árbol en el AST Explorer. También vale la pena mencionar que el árbol es básicamente un objeto JavaScript. No hay nada realmente nuevo aquí. Al igual que una etiqueta HTML en la parte superior de una página web, que es el nodo superior del árbol en el DOM, la parte superior del AST es el nodo del programa. Este nodo del programa tiene nodos secundarios como los que están debajo de body. Aquí tenemos múltiples declaraciones de importación y estas declaraciones de importación tienen nodos secundarios propios y así sucesivamente. Hay otro tipo de propiedad en un nodo que es muy importante, el tipo. Así es como le diremos a ESLint qué nos importa. Le diremos esto para este tipo de nodo. Queremos saber sobre él y ESLint se encargará de recorrer el árbol y cada vez que encuentre un nodo que nos importa, lo pasará a una función que podemos controlar y definir. También hay algunas propiedades para describir cada nodo, como el tipo de origen que es módulo en el programa. Hay otros valores que podemos ver que pueden ser realmente útiles dependiendo del nodo con el que estemos trabajando. Al observar esto, obtenemos todo lo que necesitamos para detectar patrones, que es lo que hace una regla de ESLint.

Veamos un código de ejemplo que incluye importaciones para nuestros componentes. En la parte superior izquierda tenemos algunos ejemplos diferentes, en realidad unos pocos. Primero tenemos la situación no preferida donde tenemos un componente de control segmentado que proviene de nuestro paquete principal CanvasKit React aquí. Eso no es preferido porque tenemos uno más nuevo en CanvasKit Preview React. Este es nuestro paquete de vista previa. Queremos dirigir a los desarrolladores a usar eso en lugar de nuestro paquete principal en algún momento. Cuando seleccionamos la transformación para ESLint V8, obtenemos un código de ejemplo en la parte inferior izquierda. Esto es genial porque nos dará un punto de partida. Lo he limpiado un poco hasta lo esencial. Lo que tenemos es una función create. Esta función create devuelve un objeto literal.

Este objeto que devuelve puede tener cualquier número de propiedades. Estas propiedades son los tipos de nodos que nos importan. En este caso, el ejemplo tiene una plantilla literal. Cada vez que hay una plantilla literal, se obtendrá ese nodo. Y de inmediato informará que tenemos una plantilla literal. Sin embargo, no nos importan las plantillas literales.

Nos importa otra cosa aquí. Haga clic en la declaración de importación en nuestro código. Esto resaltará algo en la vista del árbol. Y aquí vemos una declaración de importación. Eso es lo que nos importa. Queremos examinar estas declaraciones de importación y echar un vistazo más de cerca.

Entonces cambiemos esto a declaración de importación. Y ahora tenemos una regla que se aplica a todas estas declaraciones de importación. Muy bien. Ahora estrechemos el enfoque. No queremos informar cualquier declaración de importación. Queremos hacerlo condicionalmente. Así que voy a crear un par de condiciones que queremos buscar. Queremos buscar cuando estamos importando desde el paquete principal. Entonces, es paquete principal. Solo voy a poner true por ahora. Luego también queremos buscar el nombre del componente, que es segmented control. Así que vamos a decir, es segmented control. Genial. También voy a decir que eso es true. Y luego voy a envolver este context.report en esas dos condiciones. Y vamos a hacer que esas condiciones sean funcionales. Estas dos condiciones son true. Eso es lo que queremos saber.

Y ahí vamos. Muy bien. Vamos a hacerlos inteligentes ahora. OK, mirando el paquete principal, sería esto aquí. Queremos verificar si este valor está ocurriendo en una parte del nodo. Así que si miramos el nodo, tenemos la declaración de importación. Vemos que estamos tratando con una source. Y el valor está bajo source.value. Así que podemos mirar el node.source.value y compararlo con este valor aquí, que es el paquete principal ahí. Muy bien, déjame indentar esto un poco para que sea un poco más legible. Es un poco más grande aquí. Genial. Entonces esa es la primera condición. Y ya podemos ver que se reduce a solo una situación aquí. Eso es bueno.

La otra condición que queremos mirar es si es el control segmentado. Así que si hacemos clic en control segmentado, esto enfocará los nodos apropiados en la vista del árbol. Y podemos ver que hay un imported y un local. Si miramos otro, podemos ver que el local es a lo que le asignamos un alias, si eso es diferente. Y el imported es el nombre que el paquete nos está dando. Así que aquí en este ejemplo, en realidad son uno y el mismo, pero es el imported.name que nos importa del nodo. Así que vamos a mirar eso. Vamos a mirar el node.imported. Lo siento, en realidad me salté algo aquí. Esto está bajo los specifiers. Muy bien, así que necesitamos mirar los specifiers. Y esto es un array, así que necesitamos encontrar algo en el array. Necesitamos encontrar un control segmentado para saber que estamos tratando con algo que nos importa. node.specifiers. Podemos encontrar dentro de aquí, y luego eso nos dará un specifier.

Y queremos buscar cuando specifier.imported.name coincide con el control segmentado. Muy bien, movamos esto a su propia línea. Formateemos esto un poco para que sea fácil de leer. Genial. Y todavía está encontrando solo ese ejemplo. Permítanme quitar, o veamos. Estamos filtrando en función de eso, o filtrando en función de eso. Muy bien, intentemos cambiar algunas cosas. Tomemos esto y hagámoslo un poco diferente. La regla no se activa, así que estamos filtrando correctamente ese nombre. Y si cambiamos esto a otra cosa, no se activa en eso. Ese ni siquiera es un nombre válido, pero simplemente lo volveremos a poner. Genial.

Esta es nuestra primera regla de ESLint. En resumen, aquí tenemos un retorno de un objeto, y estamos definiendo el tipo de nodo que nos interesa, la declaración de importación. Tenemos algunas condiciones que examinan diferentes hijos y diferentes propiedades de ese nodo, como mirar la fuente y mirar su valor, mirar a través de sus especificadores, iterar a través de ellos y encontrar uno que coincida con un nombre que nos interesa. Y cuando suceden esas cosas, oh, vamos a dar un mensaje útil. Hay una versión preferida en vista previa. Ahí vamos. Ahora, si venimos aquí a la derecha en la salida, podemos ver que estamos dando un mensaje útil a los desarrolladores que usan nuestro proyecto. Hay más cosas que podemos hacer, como mover este indicador de posición que indica dónde debemos hacer un cambio hacia donde tenemos el nombre del paquete. Y podemos hacer cosas como escribir pruebas y todo eso. Pero esta es solo una buena y rápida regla de ESLint que escribimos que sería muy útil para nuestros usuarios. Así que veamos qué más haríamos.

Como estaba diciendo, si tuviera que empaquetar esta regla y prepararla para los consumidores, escribiría un conjunto de pruebas y agregaría soporte para otros componentes duplicados que tenemos en nuestra próxima versión, recomendando cuál es preferido para cada uno, si hay uno en vista previa o laboratorios que las personas deberían usar cuando estén listas. También existe la opción de implementar un fixture en ESLint, que es esencialmente una modificación de código. No hice eso porque hay otra herramienta que veremos que está dedicada a ese propósito, especialmente cuando estamos haciendo cosas como lo que estamos haciendo con cambios de API rotos. Veamos las modificaciones de código a continuación. Una modificación de código automatiza una refactorización de código o un cambio en la sintaxis. Pueden ser escritas por los mantenedores de una biblioteca, los usuarios de una biblioteca o realmente cualquier desarrollador que tenga una serie de cambios para aplicar en un código base.

Los code mods son excelentes para mejorar la rapidez con la que los consumidores pueden actualizar, por ejemplo, a una nueva versión principal que tiene cambios rotos. No necesitan cambiar manualmente su código y solo pueden ejecutar un script. Eso es bastante fácil. También son excelentes para realizar cientos o incluso miles de pequeños cambios repetitivos. Preferiría pasar una hora escribiendo código para un code mod que editar a mano cientos de archivos, lo cual puede llevar más tiempo y resultar fácilmente en errores. En particular, si estás manteniendo una biblioteca, es algo que podría ser realmente valioso para tus usuarios.

Permíteme compartir contigo mi primera experiencia usando un code mod. En 2018, estaba trabajando en un equipo de productos. Estábamos cambiando nuestra biblioteca para CSS y JS y componentes estilizados. Nos estábamos moviendo de glamorous a emotion. Y mientras considerábamos nuestras opciones y el esfuerzo requerido, encontramos un code mod de otro ponente en esta conferencia, Tejas Kumar. Tejas es fantástico, al igual que su trabajo. Su code mod fue perfecto para ayudarnos a migrar. Lo ejecutamos en nuestra base de código y nos ahorró la mayor parte del esfuerzo. Avancemos rápido hasta 2021, y en mi equipo de diseño de sistemas, estábamos lanzando una versión principal de nuestra biblioteca que tenía algunos cambios importantes en nuestras APIs. Así que decidimos comenzar a incluir code mods para facilitar las actualizaciones de los equipos. La herramienta más popular para escribir code mods es JS CodeShift.

Volviendo a AST Explorer, veamos un ejemplo. Revisando mi ejemplo anterior, a menudo promocionamos componentes de nuestros paquetes de Labs y Preview a Main. Veamos un caso en el que queremos actualizar el paquete de importación de Preview al de Main. Digamos que estamos promocionando un control segmentado en nuestro próximo lanzamiento, y ya hemos configurado el analizador como Babel y la transformación como JS CodeShift. Nuevamente, esto nos dará un código de inicio muy útil en la parte inferior izquierda. Todavía tenemos nuestra vista de árbol en la parte superior derecha, y tenemos alguna salida y depuración en la parte inferior derecha. El ejemplo predeterminado es un poco divertido. Está buscando identificadores, como control segmentado y menú aquí, y simplemente invierte las cadenas. Bonito. Ahora hay algunas diferencias en cómo se escribe un code mod de JS CodeShift en comparación con una regla de ESLint. También hay algunas similitudes. Al igual que antes, queremos hacer coincidir un cierto identificador para asegurarnos de un cierto tipo de nodo. Y luego, para un tipo de nodo dado, queremos buscar situaciones que nos interesen, como reemplazar todos los identificadores en este ejemplo.

Lo que es diferente aquí es que estamos haciendo cosas como obtener el origen y tenemos esta API de encadenamiento. Hay algunas cosas que podemos hacer para separar eso, pero esto está bien por ahora. También hay esta API j. Eso es code shift de api.js, y la convención es aliasarlo como j, para que podamos acceder fácilmente a cosas como j.identifier, que crea un nuevo nodo de identificador. Por lo tanto, podemos crear nuevos nodos y manipular los existentes y realmente mutar lo que tenemos para cambiarlo según nuestras necesidades.

Entonces, volviendo a nuestro ejemplo, tenemos esta cadena aquí en la vista previa en el nombre del paquete. Y eso es lo que queremos cambiar. Queremos eliminar esa vista previa y hacer que importe desde el paquete principal, porque estamos promocionando esto al paquete principal. No queremos mutar esto. Hay otro componente del menú. Eso todavía está en vista previa, y eso no se está promocionando todavía. Entonces veamos qué se necesita para modificar esto.

De acuerdo. Como antes, estamos trabajando con una declaración de importación. Así que vamos a tomar eso. Y vamos a encontrar todos esos. Bien, vamos a encontrar todas las declaraciones de importación. ¿Y qué hacemos a continuación? Filtramos solo las que coinciden con la ruta que nos interesa. Así que podemos hacer un filtro. Y en lugar de solo un nodo, en realidad tenemos una ruta que contiene un nodo. Así que vamos a tomar la ruta aquí y pasarla a la función. Y nos importa path dot, ¿qué es esto de nuevo? Nuevamente, usaré la vista de árbol. Haré clic en la cadena. Y estamos viendo el valor de source de las declaraciones de importación. Genial. Entonces, path dot node dot source dot value. Y vamos a verificar si coincide con el valor actual. Y por un momento, voy a tomar, voy a tomar toda esta cadena y hacer una variable para eso. Eso es muy útil. Eso es el antiguo import.

Y también vamos a hacer una nueva importación. Lo agregaremos. Y eso será lo mismo sin esa parte de vista previa. Genial. Muy bien.

Entonces vamos a comparar ese valor de origen del nodo. Cuando coincida con la importación antigua, eso es lo que nos importa. Y luego, para cada uno de esos casos que encontremos, queremos reemplazarlo. No con un identificador, sino con una declaración de importación. Y vamos a crearlo así. Permítanme deshacerme de todo eso. Y esto es bueno. Tenemos un poco de sugerencia de código aquí que dice que primero necesitamos los especificadores. Y luego lo segundo que necesitamos es el valor de origen. Lo bueno es que podemos reutilizar los especificadores de la importación actual. Y podemos ir a path. ¿Cómo se llamaba esto de nuevo? Esas son estas cosas. Path.node.specifiers. Eso es todo. Path.node.specifiers. Node.specifiers. Y lo segundo sería la nueva importación. No podemos simplemente darle un valor de cadena. En realidad, tenemos que darle un tipo de nodo AST. Y podemos crear eso usando J.string literal. Darle ese valor de cadena nos dará algo que podemos usar aquí. Y oh Dios mío, creo que funciona. Echemos un vistazo. Entonces import segmented control. Ahí está.

Ya no tenemos la vista previa allí. Hemos actualizado esto de manera efectiva y no hemos tocado la otra importación que no queríamos cambiar. Volviendo a la fuente para revisar rápidamente. Estamos buscando por un cierto tipo de nodo. Estamos filtrando en función de algunos criterios como la antigua importación presente aquí. Y luego estamos reemplazando un nodo que nos importa, en particular esta declaración de importación. Estamos dando una nueva declaración de importación. Usando los especificadores aquí y luego pasando el nuevo valor de importación que es el paquete principal. Y estamos promocionando nuestros componentes. Esto es lo que hacemos cuando promocionamos cosas en nuestras nuevas versiones importantes. Tenemos algunos code mods más complejos que manejan otros casos especiales, pero esto te da una idea básica de lo que está sucediendo.

Genial. Código en vivo, divertido. OK. He escuchado esto mucho de muchas personas con las que hablo e incluso he visto algunos de los desafíos dentro de mi propio equipo. No siempre es fácil escribir code mods buenos que funcionen en todos los casos de uso. Los code mods pueden ser complicados de escribir, y es fácil modificar accidentalmente código que no pretendíamos modificar. Necesitaremos buenos tests. Podemos solucionar esto extrayendo utilidades para abordar problemas comunes en nuestro dominio, teniendo un conjunto de casos de prueba que siempre aplicamos a un cierto tipo de code mod. Y echa un vistazo a Codeshiftcommunity.com. Es un proyecto de comunidad que ofrece ejemplos realmente buenos, mejores prácticas y algunas herramientas que incluso puedes importar para facilitar la escritura de tus code mods.

Este mes, nuestro equipo lanzó una nueva versión importante con cambios disruptivos. Y tuvimos varios cambios en las API de componentes, lo cual podría molestar a nuestros usuarios, pero en cambio, esto es una de nuestras reacciones. Hola, equipo. Oyente de toda la vida, primer llamador. Solo quería mencionar lo increíble que fue usar el code mod V9. Hizo que la actualización fuera tan, tan fácil. Me encanta ver esto. Nunca he conocido a Simon, pero tiene mucho respeto en nuestra comunidad, así que esto significó mucho viniendo de él. Y este tipo de comentarios en realidad son bastante típicos cuando estás automatizando todos los cambios disruptivos y haciendo las actualizaciones lo más sencillas posible.

Apenas estamos rascando la superficie de lo que podemos hacer con la construcción de nuestras propias herramientas. Cada vez que haces esto, estás mejorando la experiencia del desarrollador para ti mismo y para todos los demás desarrolladores en tu comunidad. El impacto puede ser masivo, tal vez 10 veces, tal vez 1,000 veces. Más importante aún, la satisfacción es inmensurable.

Los desarrolladores aprecian cuando su trabajo se vuelve más fácil. Construir herramientas que resuelvan un problema es de lo que trata toda nuestra carrera. Hacer esto el uno para el otro es una de mis formas favoritas de trabajar. Espero que ahora tengas algunas ideas sobre cómo comenzar a construir tus propias herramientas JavaScript.

Para obtener más información sobre cómo trabajar con ESLint, recomiendo su documentación en eslint.org. Si estás trabajando con codemods, el mejor lugar para ir es el sitio web de la Comunidad CodeShift. Y para una revisión rápida de todo de lo que acabo de hablar, enlaces a aún más recursos, visita un sitio que construí, astsareawesome.com. Gracias a todos por escuchar. Por favor, envíenme sus preguntas, ideas y pensamientos sobre este tema en cualquier momento. Gracias. Gracias.