Bundlers: Una Profundización en las Herramientas de Construcción Modernas de JavaScript

Hola a todos. Soy Edoardo. Soy DevRel en Storyblok. Y en esta charla, los guiaré en una profunda inmersión, una exploración del mundo de los empaquetadores de JavaScript. Veremos por qué necesitábamos hacer empaquetadores en primer lugar. Luego intentaremos aprender programando, aprender haciendo un paquete simple. Creo que la mejor manera de aprender algo es hacerlo realmente. Así que veremos cómo podemos hacerlo.

Compartiré el resultado final de esto en un repositorio de GitHub. Así que no se preocupen por estudiar todos los fragmentos que compartimos. No se preocupen. Es solo para introducirlos a algunos conceptos básicos. Cuando conocemos los conceptos básicos, podemos entender algunos conceptos más avanzados. Y en la parte final, veremos por qué Vite es diferente de Vite.

Primero que todo, en Storyblok en los últimos meses, estuvimos en un proceso de migrar todos nuestros SDKs y bibliotecas de JavaScript a Vite. Y esto fue realmente interesante para mí. Así que aprendí mucho. Aprendí sobre empaquetadores y sobre Vite. Les sugiero que revisen la página de GitHub de Storyblok cuando puedan ver todas nuestras bibliotecas de JavaScript. Y cómo usamos y configuramos Vite. Y en este proceso, descubrí sobre Vite. Y esto me inspiró a hacer esta charla, básicamente.

Storyblok también apoya activamente el proyecto Vite y la comunidad de Vite. Así que solo puedo agradecer a Storyblok por eso.

Entonces, comencemos con un ejemplo. Esto es como una antigua API de JavaScript. Esto es como una antigua aplicación de JavaScript. Cuando cargamos cada parte de nuestra aplicación juntas en un index.html. Así que tenemos una aplicación web. Y puedes ver que cargamos cada archivo de JavaScript aquí. Porque esto era lo que se hacía en ese momento.

¿Cuál es el problema? No es importante lo que esta aplicación está haciendo. Es solo como registrar algo. Pero lo que es importante es ver que lo que estamos usando de otros módulos, otros archivos. No podemos predecir. Porque como este comentario, por ejemplo. ¿Qué resultado estamos obteniendo? Con esta función de formato de fecha. ¿Qué datos de formato estamos usando? No hay importación en la parte superior. Todo es global. Así que aquí tenemos funciones. Tenemos funciones de formato. Tenemos variables. Pero no sabemos qué estamos usando. ¿Verdad? Así que con este primer ejemplo, tenemos problemas. Tenemos problemas con el conflicto de nombres de variables. Con la sobrescritura de funciones. Que el espacio de nombres global está contaminado. Y no podemos realmente controlar el orden de las dependencias. Pero sabemos que todos estos problemas se resuelven usando ES modules.

Así que déjame compartir esta segunda aplicación donde el index.js, cargamos ese único archivo. Pero con el atributo type module. Con el atributo type module, el navegador sabe que index.js está usando ES modules. De hecho, la lógica de negocio de index.js es la misma. Pero ahora estamos usando declaraciones de importación. Así que estamos seguros de que, por ejemplo, aquí el nombre de la aplicación proviene de utils. Formatear datos también. Y tenemos un formato de fecha que está sobreescrito. Pero lo aliasamos con un nombre diferente. Así que podemos controlar las cosas que estamos importando. Y también el orden de las dependencias. Y todo simplemente funciona.

¿De acuerdo? Pero necesitamos verificar la compatibilidad del navegador para eso. Podemos estar seguros de que es compatible en todos los navegadores principales. Así que para la compatibilidad, está bien. Sin embargo, para el rendimiento, hay algunos problemas. Porque por cada archivo individual que estamos cargando en nuestra aplicación, el navegador hace una llamada HTTP. Así que tenemos múltiples llamadas HTTP. Y esto es más importante. Cuando solo necesitamos una función o una cosa de un módulo, el navegador necesita cargar toda la biblioteca, todo el archivo, que incluye esa única función que necesitamos. Y esto no está bien para el rendimiento.

¿De acuerdo? Necesitamos llegar aquí. Estas son las primeras líneas de la biblioteca cliente real de Story Block JS que puedes ver en GitHub. Y este es el bundle. ¿De acuerdo? Así que en este archivo, ves que todo está empaquetado junto y está optimizado. Y solo tenemos unos pocos archivos que el navegador necesita cargar. Así que queremos llegar aquí. Así que déjame presentarte al mini-bundler. El mini-bundler es lo que podemos llamar un bundle. Porque esta vez en nuestro index.

Así que podemos esperar que todo esté empaquetado junto en este bundle. Así que si te muestro el bundle de la carpeta dist, ves aquí que tenemos una sola carpeta con todo dentro.

¿Cómo hicimos eso? El concepto básico es que necesitamos entender las dependencias en nuestra aplicación. Así que necesitamos comenzar desde un punto de entrada. En la mayoría de los casos, sería el main.js o el index.js. Comenzamos desde el punto de entrada. Y luego comenzamos a rastrear para construir un gráfico de dependencias.

Cuando tenemos una estructura que representa nuestro gráfico de dependencias, entonces podemos generar un bundle a partir de él. Y luego solo podemos tomar el bundle y escribirlo en un archivo. No mucho más. Como, solo necesitamos funciones o métodos para leer el contenido del módulo, para construir un gráfico, para transformar el contenido del módulo.

Necesitamos transformar porque tenemos módulos ES, así que tenemos imports y exports. Pero en el bundle final, necesitamos tomar la función completa y ponerla en el contenido del módulo. Sin depender de dependencias externas. Porque manejamos todo. Así que necesitamos transformar el contenido del módulo. Y en realidad es muy simple.

El resultado final es este. Quería mostrarte que en el archivo del bundle, la estructura que usamos para representar el gráfico de dependencias es solo un objeto. Y las entradas en este objeto son la ruta a los módulos. Y para cada entrada, tenemos un ID, tenemos la ruta del archivo, el contenido, el contenido completo del módulo o del archivo. Y dependencias, imports y exports.

Así que definimos y describimos cada módulo de nuestra aplicación aquí en este objeto, que es nuestro gráfico de dependencias. Y a partir de eso, construimos nuestro bundle. El resto del bundle simple es realmente simple, de hecho. Ves que estamos usando RegExp para tomar imports y exports. Y este es, por supuesto, un enfoque simplificado. Y luego transformamos.

Una parte interesante es que cuando escribimos el contenido en el archivo del bundle, envolvemos todo en una función autoejecutable. Porque entonces el navegador sabe que puede simplemente ejecutar lo que hay en el archivo. Y dentro de esto, comenzamos definiendo una función require. Y la función require es como un require común de JS simplificado. Con esto, tomamos funciones o variables de otros archivos y las ponemos en el archivo que estamos leyendo o ejecutando. Y con este enfoque simple, podemos juntar todo y podemos decirle al navegador qué hacer. De hecho, si miras el código, estamos simplemente definiendo el require aquí y luego comenzando desde el índice.

Así que desde el punto de entrada, estamos tomando, por ejemplo, el formato day, que es una función que utiliza el require de una ruta y toma la función. Esto es como el común de JS. OK. Y luego tenemos el contenido de los módulos. Empacamos todo en el contenido del módulo y luego tenemos la lógica de negocio y la ejecutamos. Esto para cada módulo en nuestra app. Todo está en un solo archivo, ¿verdad?

Espero que esto sea simple de entender. Este enfoque es realmente similar al original de webpack. De hecho, si miras el bundle producido por webpack, es realmente similar a lo que tenemos. Ves, tienes el require de webpack en la parte superior. Tienes una función autoejecutable y tienes el gráfico de dependencias. Los bundles modernos, en comparación, tienen un sistema de módulos más sofisticado y cosas más sofisticadas con webpack 5. Roll up está más optimizado para módulos ES y ES build está escrito en Go. Así que tiene mejores rendimientos y puede aprovechar el procesamiento paralelo. También tiene soporte nativo para TypeScript.

Estos son los tres empaquetadores más comunes. OK, pero espera, ¿cómo estamos analizando el código de nuevo? Recuerda, estamos usando RegExp para importaciones y exportaciones, pero esto no es bueno. Así que necesitamos introducir un concepto ligeramente más avanzado, que es el árbol de sintaxis abstracta o AST. El AST es una estructura de datos que podemos usar para representar un programa o un fragmento de código, es una representación en árbol de la estructura sintáctica de un texto. Puede ser un código fuente. OK. Y esta representación formal está escrita en un lenguaje formal. Así que cada nodo es cada nodo es un constructo en nuestro texto.

Por ejemplo, aquí tienes un código JavaScript muy simple, pero lo traducimos al árbol de sintaxis abstracta. Y esta estructura es muy fácil para que una máquina la explore. Así que la máquina toma nodo por nodo y puede pasar esto fácilmente. Si quieres una representación más humana. Aquí estamos. Este es el árbol de sintaxis abstracta del código, el fragmento de código que vimos. Así que tenemos analizadores, tenemos analizadores ampliamente utilizados en el mundo de JavaScript. Tenemos Acorn, que es muy ligero y tenemos el analizador Babel, que es más avanzado. Para usar Acorn, solo necesitas requerir Acorn y llamas al método parse de Acorn, obtienes el AST.

Así que quiero presentarte el empaquetador simple, que es la versión final de nuestro proyecto. Y en esta versión, encontrarás el código en GitHub. Esto es un poco más complejo, así que no puedo guiarte a través del código. Pero la modificación principal es que ahora pasamos el contenido usando Acorn. Así que en el módulo de lectura, en lugar de depender de importaciones y exportaciones, como EXP, ahora transformamos el contenido del módulo con el AST. Y usamos el AST para recorrerlo y extraer importaciones y exportaciones y también para transformar el código. Esta es la modificación principal que tenemos. Así que, dado que queremos llegar aquí, recuerda dónde estábamos con nuestro empaquetador simple, con nuestro mini empaquetador, estábamos aquí. Tenemos este bundle. Queremos tener este. Así que no solo necesitamos cambiar la forma en que transformamos, sino que también necesitamos minificar esto en esta cosa. Para hacer eso, añadí otra dependencia, que es Tercer, que es otro plugin que utiliza Acorn para minificar cosas.

Y el proceso de minificación también optimiza el bundle. Así que en nuestro bundle simple final, puedes revisar el código nuevamente en GitHub. Todo esto está implementado. Además, implementé una forma de usar plugins, que es nuevamente similar a lo que Webpack está haciendo con el uso de hooks. Así que tenemos hooks en pasos específicos en nuestro código. Y en estos pasos, podemos llamar a otras funciones. Por ejemplo, implementé un plugin que utiliza Tercer, implementa el hook de bundle, y luego llamamos a minify de Tercer para realmente minificar el bundle final. Así que este es el paso de bundle al final del proceso. Para todo lo demás es lo que vimos en las diapositivas. Así que más o menos es como el mini bundler, pero un poco más complejo y usando el Acorn AST para hacer cosas y analizar código. Pero nuevamente, siéntete libre de ir a GitHub y jugar con esto y mirarlo.

OK, así que este es el resultado final. Cada archivo en mi aplicación ahora está empaquetado y agrupado en un solo archivo, que es este. Ahora algunos conceptos más avanzados, el tree shaking. Tree shaking es la eliminación de código muerto. Así que básicamente, si tenemos código al que no podemos acceder o que no usamos en la aplicación final, simplemente lo eliminamos del bundle. Así que, por ejemplo, en este caso, en Nutils, tenemos subtract y divide que no usamos en la aplicación. Así que el bundle final no contendrá esa función. Las eliminamos. Así que esto es sacudir el árbol y las ramas muertas simplemente salen. Luego tenemos la división de código. Ahora ves un solo bundle con todo. Podemos tener bundles separados de la división de código, que es la práctica de dividir el código en múltiples fragmentos. Y podemos hacer eso con este pseudocódigo simple. Cuando añadimos el nuevo módulo, que es generate chunks y para cada importación dinámica. Cuando tenemos una importación dinámica, simplemente llamamos a una nueva función. Construimos un nuevo grafo de dependencias y generamos un nuevo fragmento. Así que definimos que una carpeta dist estará compuesta por el bundle y luego fragmentos, que son archivos diferentes.

Entonces, otro concepto, el hot module replacement. Los bundles modernos todos tienen hot module replacement. Es cuando estás trabajando en tu aplicación localmente y cambias el código fuente. Cuando cambias el código fuente, no quieres recargar toda la aplicación, sino solo la parte que cambiaste. Con el hot module replacement, solo le dices al navegador que recargue solo esa parte específica. Y podemos hacer eso usando un watcher y usando sockets. Así que con sockets, simplemente enviamos al navegador un JSON. Por ejemplo, cuando le decimos al navegador que reemplace solo un chunk específico o un módulo específico.

Ahora, para esa parte final, puedo presentarte a VIT. Sabiendo todo lo que ahora sabemos, podemos entender que VIT no es exactamente un bundler. De hecho, ellos se llaman a sí mismos un no bundler. ¿Por qué? Porque VIT es como un orquestador de bundlers. VIT está usando y optimizando otros bundlers. Así que otros bundlers son dependencias para VIT. En VIT, tenemos el modo dev y el modo producción. El modo dev está usando ES build. Así que cuando construimos cosas en modo dev, estamos usando ES build. Y tenemos hot module replacement. Tenemos pre-bundling de dependencias. Tenemos optimizaciones. En modo producción, en cambio, tenemos rollup. VIT está usando rollup.

Así que el bundle final para producción está fuertemente optimizado por rollup y por configuraciones opinadas hechas por el proyecto VIT. Esta es una comparación simple entre VIT y un bundle simple en la aplicación final de producción. Mencioné que el pre-bundle de dependencias, si miras a VIT cuando estás en modo desarrollo, verás esto en la consola, pre-bundling de dependencias. Esto significa que las dependencias de tu aplicación están siendo optimizadas. De hecho, cuando miras el código final de producción y el código empaquetado, verás que, por ejemplo, use state no proviene de React, sino de módulos React, porque está pre-bundled y optimizado por VIT. O aquí, por ejemplo, en producción, tenemos aquí configuraciones opinadas con rollup. En cambio, en modo desarrollo, tenemos un servidor web. Lo siento.

Ahora con VIT, obtenemos un inicio de dev más rápido. Tenemos un mejor rendimiento de dev y tenemos soporte nativo de ESM. Por supuesto, también tenemos más agregados de mapas, así que la experiencia de desarrollo con VIT es realmente mejor y son opinados, utilizan el enfoque opinado para preconfigurar y preoptimizar tus bundles por ti. También tenemos un mejor HMR. Así que para el modo de desarrollo y producción, todo está optimizado y es mejor. Necesitamos entender que también necesitamos navegadores modernos para aprovechar y utilizar completamente las características de VIT.

Que hay diferencias en el bundle de dev y el bundle de producción, porque estamos usando diferentes bundles. Y en modo de desarrollo, todavía tenemos muchas solicitudes HTTP. Así que por favor ten en cuenta estas limitaciones. No son limitaciones, pero ten en cuenta eso.

De nuevo, este soy yo. Puedes encontrarme en Mastodon. Puedes encontrarme en mi canal de YouTube. Puedes encontrarme en mi LinkedIn si quieres contactarme. Estoy disponible para responder todas tus preguntas. Puedes unirte a la comunidad de Storyblok. Tenemos nuestro Discord y tenemos nuestros embajadores. Revisa esta página. Y como prometí, el código de Simple Bundler está en GitHub.