El Superpoder de los ASTs: Cómo Ahorramos un 16% en el Tamaño de Nuestro Bundle

♪♪ {{^}}♪♪ {{^}}♪♪ Tómate un momento para pensar qué significa esto para ti. Así que probablemente pienses que esto es un bundle, pero lo más probable es que pienses que esto es doloroso, porque nosotros, como desarrolladores front-end, pasamos mucho tiempo y esfuerzo en reducirlo tanto como sea posible. Nuestra historia trata sobre una super herramienta que usamos para reducir el tamaño del bundle, y nos llevó de aquí a allá sin cambiar una sola línea de código. ¿Y si tú también pudieras tener una super herramienta que eliminara automáticamente 4,250 declaraciones de entrada mientras mejora tu rendimiento en un 16% más que el tree shaking de Terza, que se considera el estado del arte en cuanto a optimización de bundle? Además, reducirá 14 megabytes de tu tamaño de bundle, lo cual es realmente mucho. Hola, soy Omri Lavi. Soy líder técnico en el grupo de DevTools de Monday. Esto significa que estoy construyendo herramientas para desarrolladores para que puedan trabajar con mayor velocidad y con mayor confianza. También soy parte del grupo de Foundations, así que esto me da oportunidades únicas para trabajar en cosas realmente interesantes como la que hablaré hoy. Para darte un poco de contexto, en Monday.com, tenemos un código cliente grande y complejo. Tenemos más de 300 desarrolladores cambiando el código cliente a diario, y tenemos millones de usuarios, por lo que cada kilobyte que ahorramos importa mucho. Es por eso que buscamos formas innovadoras de reducir el tamaño del bundle tanto como sea posible.

Y hace un tiempo, notamos el siguiente patrón. Vimos que teníamos muchos archivos que se veían así. Exportaban objetos anidados que al final del día solo contenían cadenas. Por eso los llamamos archivos de constantes.

Y los archivos que referenciaban los archivos de constantes solo usaban uno o dos valores de estas constantes. Así que probablemente estés pensando, está bien, tengo Tree Shaking exactamente para este caso, y si no estás familiarizado con Tree Shaking, entonces es un algoritmo muy común que la mayoría de los empaquetadores usan hoy en día para eliminar los valores no utilizados de tu bundle, así que terminarás exactamente con lo que necesitas en tu bundle. Pero en nuestro caso, Tree Shaking no funcionó correctamente porque usamos objetos, y Tree Shaking no maneja bien los objetos. Así que terminamos con algo como esto en nuestro bundle, y ves que todas las partes rojas son en realidad archivos de constantes.

Y el problema con eso es que tenemos muchos archivos de constantes dentro de nuestro bundle. Esto significa que tenemos más JavaScript del que realmente necesitábamos. Esto aumentó el tamaño de nuestro bundle y lo hizo más pesado para la red, por lo que nuestra aplicación se volvió más pesada de cargar. Además, todos estos archivos se mantenían en memoria y nunca se eliminaban, por lo que aumentó nuestra huella de memoria más de lo que queríamos. Y se sentía mucho como esto. Teníamos un pequeño fragmento de código que llevaba un gran equipaje con él.

Así que teníamos un sueño. Teníamos un sueño de que mientras construimos el bundle, encontraremos los valores de referencia de los archivos de constantes, eliminaremos las referencias, y las reemplazaremos con los valores reales, y luego podemos eliminar la importación de estos archivos de constantes y terminar exactamente con los valores que necesitamos dentro de nuestro bundle. Así que sabíamos lo que queríamos hacer, pero no estábamos seguros de cómo hacerlo. Sabíamos que queríamos evitar grandes refactorizaciones porque teníamos mucho código que necesitaba ser actualizado, y sabíamos que queríamos evitar la actualización manual del código porque, de nuevo, era mucho código, y necesitábamos hacerlo programáticamente para evitar errores que los humanos pueden cometer. Así que después de pensar un poco, entendimos que podíamos usar ASTs, pero espera, los ASTs no son muy comunes, ¿verdad? Piensa por un momento si alguna vez has usado ASTs antes.

Así que la verdad es que todos usamos ASTs, y simplemente puede que no lo sepamos, y lo veremos en un segundo. Así que los ASTs son árboles de sintaxis abstracta. Es una estructura de datos usada para representar un fragmento de código, y la mejor manera de entenderlo es mediante una herramienta llamada AST Explorer. AST Explorer es una herramienta en línea gratuita, y puedes poner un fragmento de código en ella, como el que está aquí, y te mostrará su AST. Puede parecer aterrador a primera vista. Realmente lo es, pero el poder de AST Explorer es que puedes seleccionar un fragmento de código, y te mostrará su nodo correspondiente en el AST. Así que, por ejemplo, puedes ver aquí que tenemos un nodo de literal de cadena con el valor de hey, Berlin. También podemos seleccionar esta parte aquí para ver que es un nodo de declaración de variable con el nombre de hi, el valor de hey, Berlin, y también podemos ver que su tipo es const. Es importante entender que los ASTs realmente todos. Muchas herramientas usan AST. Si piensas en ESLint, PostCSS, Prettier, Webpack, y muchas otras herramientas, todas usan AST para leer y transformar código programáticamente.

Tomemos, por ejemplo, cómo funciona Prettier. Supongamos que tengo este fragmento de código que usa comillas simples, y cuando guardo el archivo, entonces Prettier se ejecuta en segundo plano y actualiza el archivo y actualiza el código para que sea así. El resultado es que tiene comillas dobles. Y la forma en que funciona detrás de escena es que tiene este fragmento de código que dice que si ves un nodo de cadena con un tipo de comilla simple, entonces establece su tipo de comilla en doble. Y esta parte aquí es en realidad código AST. Esta es la magia y el motor detrás de Prettier que le permite ser tan poderoso.

Así que sabíamos que necesitábamos ASTs, pero ¿qué herramienta, qué framework deberíamos usar? Sabíamos que necesitábamos algo que nos permitiera manipular código usando ASTs. Queríamos que la herramienta fuera popular, para poder disfrutar de la comunidad que trae consigo. Queríamos que fuera flexible, para que nos permitiera hacer exactamente lo que queremos. Y por último, queríamos que fuera enchufable, para poder usarla en nuestro ecosistema existente sin hacer cambios importantes. Así que después de investigar un poco, decidimos usar Bubble. Y Bubble tiene todas estas características, y puede que lo reconozcas de tu configuración web, donde es muy popular.

Así que entendamos cómo funciona Bubble detrás de escena. Bubble sabe cómo leer código, analizarlo en AST, luego puede ejecutar plugins para generar un nuevo AST a partir de él. Aquí es donde puedes intervenir y escribir tu propio plugin que recorrerá los nodos, los mutará, insertará nuevos o eliminará los existentes, y luego Bubble tomará el nuevo AST y creará un nuevo código a partir de él. Así que ahora que entendemos cómo funciona Bubble, volvamos a nuestro problema original. Después de un poco de trabajo, teníamos una implementación de plugin de Bubble funcionando, y funcionaba algo así. Primero, encontró todos los identificadores de referencia. Todos estos identificadores son referencias para identificadores, por ejemplo, variables o funciones y cosas así. De estas referencias, encontramos aquellas que provienen de archivos de constantes.

Luego calculamos qué valores exactos están siendo referenciados, los insertamos en lugar de las referencias, y luego pudimos eliminar las declaraciones de entrada junto con los archivos, los archivos de constantes, para terminar exactamente con el código que necesitamos. Así que esto suena muy simple, ¿verdad? ¿Qué puede salir mal con tal implementación? Así que la mejor manera de entenderlo es implementando algo nosotros mismos. Así que construyamos un mini plugin que haga algo muy similar. Supongamos que quiero manejar este caso donde estoy declarando alguna variable y luego la exporto directamente. Pero en lugar de declarar la variable, quiero exportar directamente el valor. Así que quiero escribir un plugin que actualice automáticamente el código desde arriba para que sea como el de abajo, y todo esto durante el tiempo de construcción. Así que construyámoslo juntos. Este será nuestro código de entrada, y escribiremos el plugin de Bubble en sí. Y se verá algo así.

Y parece muy aterrador, pero lo revisaremos línea por línea. Lo primero que quiero que entiendas es que Bubble te permite usar paths, y los paths pueden considerarse como nodos dentro del AST. Pero el poder de Bubble es que no obtienes cualquier path. Obtienes tipos específicos de paths según los necesites. Así que, por ejemplo, podemos pedirle a Bubble que nos dé todos los identificadores referenciados, que son los tipos de nodos que necesitábamos como te mostré antes. Así que nuestro path, por ejemplo, sería la referencia greetings aquí.

Ahora que lo tenemos, podemos acceder a su nombre, que es la cadena actual greetings. Y lo siguiente que podemos hacer es que podemos acceder al ámbito que se usa dentro de la referencia, es decir, el ámbito léxico actual que se marca aquí a la derecha. Luego podemos consultar el ámbito. ¿Cuál es el enlace para greetings, es decir, a qué se refiere realmente greetings. Así que tendremos esta variable aquí.

Necesitamos manejar el caso donde el enlace no existe. Por ejemplo, puede suceder si tenemos una referencia global. Por ejemplo, si estamos usando un console log, entonces console no está declarado en ningún lugar del ámbito léxico. Así que en este caso, saldremos temprano. A continuación, podemos acceder a la declaración de la variable y preguntar a qué se está inicializando. Así que en este caso, será este literal de cadena aquí. Así que una vez que tenemos el valor inicial real en nuestras manos, podemos acceder a nuestra referencia original nuevamente y reemplazarla con el valor que acabamos de encontrar. Y se verá así. Ahora ya no hay necesidad de nuestra declaración de variable original ya que está completamente sin usar. Así que podemos acceder al enlace y decirle que se elimine. Y terminaremos con esto, que es exactamente lo que queríamos.

Y esto se siente como magia, ¿verdad? Escribimos unas pocas líneas de código y cambiamos drásticamente cómo se comporta el código. Así que probablemente estés pensando, ¿por qué no es más común? ¿Por qué no veo más códigos ST en ningún lado? Y la mejor manera de entenderlo es jugando un juego corto. Así que juguemos una ronda de juegos de adivina el resultado. Digamos que cambio mi código. Y en lugar de declarar una variable que se inicializa a una cadena, ahora la estoy inicializando para que sea un objeto. Y luego desestructuro el objeto y exporto una de estas propiedades. Así que si piensas en lo que queríamos que fuera el resultado para este caso, queríamos que fuera el mismo resultado que antes, pero no obtendremos esto. En cambio, tendremos este resultado.

Y este es un error importante porque cambió drásticamente cómo se comporta el código. En lugar de exportar una cadena, estamos exportando un objeto. Sin duda, nos causará errores. Así que entendamos qué pasó aquí.

Cuando nuestro plugin se ejecuta, encuentra este identificador de referencia, que según nuestro código se está inicializando a este valor aquí, que es el objeto en sí. Así que insertamos este valor en lugar de la referencia, y terminaremos con este código. Y hasta ahora, todo bien. Nada realmente cambió. Funcionará de la misma manera. Pero en la siguiente fase de nuestro plugin, encontrará este identificador de referencia, y según nuestro código, se está inicializando a este valor.

Así que insertaremos la referencia con el objeto, y terminaremos con este código que no es en absoluto lo que pretendíamos. Y casos como este nos enseñaron que las super herramientas vienen con super errores. Y la razón de esto es que el código regular tiene alguna entrada de usuario sobre la que ejecutas alguna lógica para llegar a tu salida. Pero en el caso de las herramientas AST, no tienes entrada de usuario. En su lugar, tienes entrada de código. Y la entrada de código es muy difícil de trabajar. Es menos estructurada. Tiene muchos casos límite, y necesitas aprender a usarla correctamente.

En muchos sentidos, recuerda a las Regexes. Todos hemos usado Regexes antes, y vimos cómo los casos simples se vuelven muy complicados muy rápidamente. Y necesitas aprender a trabajar con Regexes correctamente para evitar las trampas. Así que con el tiempo, aprendimos a trabajar con herramientas AST, y definimos nuestras propias mejores prácticas, y queríamos compartirlas contigo hoy. Tengo docenas de consejos, pero esta charla es muy corta. Así que nos enfocaremos en dos cosas. Primero es proteger tus suposiciones. Y la segunda es escribir pruebas exactas. Así que cuando desarrolles herramientas AST, no puedes dar nada por sentado, incluso si estás usando AST Explorer.

Estás garantizado a encontrar nuevas características de JavaScript, lo cual es muy emocionante por sí mismo, pero es menos emocionante si es debido a un error en producción. Así que lo que nos gustaría hacer es proteger nuestras suposiciones. Así que, por ejemplo, en nuestro mini plugin que acabamos de escribir, sabíamos que funcionaba perfectamente para enlaces de cadenas.

Lo revisamos de arriba a abajo, y funcionó perfectamente. Y pensamos que estaría bien. ¿Qué puede salir mal? Pero tenía una suposición aquí de que siempre estamos vinculados a cadenas. Cuando hago tales suposiciones, siempre debo cuestionarlas.

Así que, por ejemplo, si tenemos este código, significa que tenemos una inicialización de variable que no está vinculada a una cadena, sino a un objeto, entonces en este caso, nos gustaría tener un buen error durante el tiempo de compilación que diga, mira, estás usando una inicialización no soportada. Aquí está el archivo. Aquí está la línea. Por favor, ocúpate de ello.

Y la forma en que podemos obtener estos errores es diferente entre los varios frameworks. Pero en términos generales, se ve algo así. Si ves un nodo de inicialización que no es un literal de cadena, entonces lanza un error. Pero no lanzas cualquier error. En el caso de Babel, por ejemplo, lanzas un error de marco de código, que te da todo el contexto que necesitas, la ubicación del nodo problemático, junto con el archivo, la línea, la columna y todo, junto con cualquier detalle que te gustaría agregar.

Y puede ser molesto recibir tales errores durante el tiempo de compilación, pero es mucho mejor que un error en producción. También sigue el principio de fallar rápido que dice que deberías fallar lo antes posible en lugar de más tarde. Y por último, permite un enfoque incremental donde estás agregando más y más capas a medida que encuentras más casos que necesitas atender. Así que recuerda, cuando estés inseguro, simplemente lanza.

Así que lanzar errores te permite un crecimiento incremental. Pero, ¿cómo sabes que el código incluso funciona en primer lugar? Así que todos sabemos que necesitamos escribir los tipos correctos de pruebas. Necesitamos escribir pruebas unitarias, todos estamos de acuerdo en eso, pero no es suficiente. Necesitamos escribir al menos pruebas de integración para asegurarnos de que toda la solución esté funcionando como un todo.

Así que necesitábamos pruebas de integración, pero para herramientas AST que tienen algunos requisitos muy específicos. Así que después de algunas investigaciones, aprendimos sobre las pruebas exec. Y las pruebas exec se ven así. Puede parecer aterrador, pero cuando miras de nuevo, es como una prueba regular. Tiene la parte it en la parte superior, tiene algunas entradas. Luego haces algo en el medio, ejecutas algo para obtener alguna salida. Y luego puedes hacer afirmaciones sobre la salida para asegurarte de que el código realmente esté funcionando como debería. Pero la entrada es en realidad código. Y lo que haces con él es que lo transformas usando el plugin que pruebas para terminar con el código actualizado.

Y luego esta es la parte mágica. Ejecutas el código actualizado para obtener su salida. Y luego puedes hacer afirmaciones sobre la salida del código actualizado. Así sabrás que tu plugin actualizó el código exactamente de la manera que querías actualizarlo. Así sabrás que no introdujo comportamientos extraños que no pretendías. Y las pruebas exec son muy poderosas. Y para nosotros, encontró muchos errores y previno muchos errores.

Y al final del día, ahorró mucho tiempo. Siguiendo estos principios, desarrollamos nuestro propio ciclo de vida de desarrollo de AST saludable. Y esta es la parte importante. Primero, comienzas implementando la solución para todos los casos conocidos que encontraste usando AST Explore. Luego proteges tus suposiciones lanzando errores significativos para los casos que no se manejan adecuadamente. Luego ejecutas tu plugin para descubrir los casos desconocidos y al encontrar estos errores significativos. Luego escribes pruebas exec para los nuevos casos que encontraste, como el que te mostré antes. Luego implementas las soluciones y aseguras que las pruebas pasen para que sepas que el ciclo está completo y todos los casos se manejan adecuadamente.

Así que siguiendo estos métodos, podemos entregar un impacto super. Pero lo más importante, tenemos una nueva super herramienta en nuestro cinturón y con suerte, tú también. Nuestras conclusiones clave aquí es que los ASTs son un superpoder. Si te enfrentas a un desafío imposible, piensa en los ASTs como una de las herramientas que puedes usar para resolverlos. Y por último, cuando lo hagas, usa el ciclo de vida de desarrollo de AST para maximizar tu impacto. Gracias.