El funcionamiento interno de la construcción de Vite

♪♪♪ ♪♪♪ ♪♪♪ ♪♪♪ Bienvenido a vidBuild. Vamos a sumergirnos en el funcionamiento interno del proceso de vidBuild para entender cómo empaqueta y optimiza tu aplicación para producción. Primero un poco sobre mí. Soy Matías Capeleto, también conocido como Patak. Soy miembro del equipo principal de Vid y del equipo principal de Vitez, que es una nueva alternativa de JS nativa de Vid. También soy miembro del equipo de Vue, y ahora me uno al equipo de Stacklists para trabajar a tiempo completo en Vid y su ecosistema.

Entonces, ¿por qué Vid? Cuando hablamos de Vid, normalmente nos enfocamos en su servidor de desarrollo. Vid no empaqueta tu aplicación durante el desarrollo, por lo que el servidor se inicia instantáneamente. Vid transforma tus módulos bajo demanda sobre ESM nativo a medida que el navegador los solicita. Y al hacerlo, ofrece un reemplazo rápido de módulos que se mantiene rápido independientemente del tamaño de la aplicación. También obtienes soporte incorporado para Typescript, JSX, PostCSS, CSS modules y más, y una potente API de complementos basada en relab para extenderlo. Por ejemplo, para usar componentes de archivo único de Vue, u otros frameworks. Pero esto es solo la mitad de la historia. Vid también brilla al construir tu aplicación para producción, y ese será el enfoque de la charla.

Primero, vamos a probarlo. Puedes ir a vid.new slash vue en tu navegador y esto abrirá un playground de stacklit que va a bifurcar el inicio de vue en el repositorio de vid. Puedes ver que podemos jugar con la aplicación antes de que podamos terminar de explicar qué está sucediendo. Stacklit está ejecutando Node en el navegador utilizando contenedores web, lo que nos brinda una experiencia casi igual que nuestro entorno local. El tamaño de instalación de vid es realmente pequeño, por lo que la instalación fue muy rápida, y desde allí el servidor de vid se inició de inmediato ya que no es necesario empaquetar tu aplicación. El navegador solicitó el index.html, encontró un script de tipo módulo, y siguió solicitando los módulos de tu aplicación. Podemos ir a este primer módulo, y puedes ver que hay una importación para app.view. Este es un componente de archivo único de vista, y el navegador no sabe cómo procesarlo. Pero en vid.config.js, hemos configurado el complemento vid.js.plugin.view, y esto permite que vid comprenda los componentes de archivo único y le dé al navegador el js y CSS que comprende. Vamos a hello world.view y modifiquémoslo para que podamos ver cómo se activa el reemplazo de módulos en caliente. Cambiemos también algunos colores aquí, y puedes ver que tan pronto como guardamos, el cambio se reproduce al instante en el otro lado. El recuento también se mantiene, el estado se preserva. Y este ciclo de retroalimentación rápida es casi el mismo que obtienes al modificar algo con las herramientas de desarrollo del navegador, y es increíble trabajar así durante el desarrollo. Ahora cerremos el servidor de desarrollo. Y cuando estés listo para implementar tu aplicación, usa fit build para empaquetar tu aplicación para producción. Fit build utiliza internamente rollup para empaquetar todos los activos de tu aplicación.

De forma predeterminada, se encuentran en la carpeta dist. Aquí puedes ver en los activos que se generó un index.js y ahora está optimizado y minimizado. Lo mismo ocurre con el CSS. Lo mismo ocurre con una imagen que se importó y se dividió un fragmento de proveedor de forma predeterminada. En el archivo de salida index.html, podemos ver que ahora estamos importando el script index y este script va a importar el fragmento de proveedor. Para evitar la cascada de carga, lo estamos precargando aquí de inmediato. También estamos vinculando la hoja de estilo CSS. Todos estos archivos tienen un hash para que puedan ser almacenados en caché en el navegador.

Si queremos verificar la aplicación empaquetada, podemos llamar a vidpreview que va a cargar directamente la aplicación en localhost para jugar con ella. Y esto no utiliza el servidor VDev, sino directamente la aplicación optimizada. Bien, sigamos adelante.

Entonces, Vite en el momento de la construcción es una configuración de rollup con opiniones. Te brinda buenos valores predeterminados para los casos más comunes y configura rollup con complementos de funciones como soporte para PostCSS, importación JSON, WASM, WorldCard y complementos de anuncios para optimizar tu código, como la minimización utilizando ESBuild, la división de código, la precarga de activos, etc. El proceso de construcción comienza con el punto de entrada index.html, como vimos, que se analiza para extraer los scripts y vincular CSS o hojas de estilo en línea. Las etiquetas de script o las importaciones apuntan a archivos TypeScript u otros tipos de archivos siempre y cuando Vite sepa cómo transpilarlos o se extienda con complementos de usuario para manejarlos, como vimos con el complemento de Vue. Lo mismo ocurre con el CSS. Tanto si están vinculados como si están en línea, se extraerán y se procesarán mediante el pipeline.

Una vez que los activos de JS o CSS se procesan mediante el pipeline y se agrupan, cada fragmento se minimiza y debemos reemplazar las etiquetas de script y enlace originales por ellos para crear el archivo de salida index.html para nuestra aplicación. Como vimos, Vite asigna un hash a estos archivos para un almacenamiento en caché sólido en el navegador y también se genera y precarga un fragmento de proveedor. Lo mismo ocurre con los estilos CSS, que se agruparán y optimizarán en consecuencia. Vite admite la división de código tanto para los activos de JS como para los de CSS, también de forma predeterminada. Cuando se encuentra una importación dinámica, se generará un fragmento Async.js y un fragmento de CSS para ella. La llamada de importación se instrumenta en el fragmento importador para precargar las dependencias y esperar la hoja de estilo CSS correspondiente. Otros activos como imágenes, videos y wasm que se importan también se procesan mediante el pipeline de construcción. Repasemos el pipeline de complementos internos para tener una idea de lo que hace Vite durante la construcción. La API de complementos de Rollup permite que Vite admita la mayoría de las funciones y optimizaciones de forma independiente como complementos independientes. Vite utiliza una versión extendida de esta API de complementos que funciona tanto en profundidad como en construcción, introduciendo nuevos hooks específicos de Vite, por ejemplo, para extender el servidor de profundidad o aumentar los límites de reemplazo de módulos en caliente. La mayoría de los complementos del ecosistema de Rollup son compatibles con Vite. Durante la construcción, estamos tratando con complementos estándar de Rollup, ya que el servidor de profundidad de Vite no está en la mesa. Los hooks más típicos que encontrarás al crear uno son Resolve.id, que te permite resolver una ruta de importación, por ejemplo, necesitamos resolver los nombres de los paquetes a su ubicación en los módulos de Node.

El gancho de carga nos permite obtener el código para un determinado id, y es útil para implementar módulos virtuales, por ejemplo. Estos son módulos que no existen en el sistema de archivos, pero los cargamos sobre la marcha. Generamos el código para ellos sobre la marcha. El gancho de transformación nos brinda la oportunidad de transpilar el código de un módulo, por ejemplo, para eliminar los tipos, la información o compilar JSX. Y con el gancho de renderización de fragmentos, podemos transpilar cada fragmento de paquete, por ejemplo, minimizándolo con ESBuild.

El primer complemento en el pipeline es el complemento de alias, y este es el complemento de alias oficial de Rollout, y como vimos, la mayoría de los complementos de Rollout son compatibles, y varios de ellos se utilizan directamente en su pipeline interno. Este complemento permite a los usuarios configurar un mapa de alias, por lo que las rutas de importación comunes pueden ser más manejables, un buen caso de uso para el gancho de resolución de ID. Por ejemplo, si hay un alias de componentes que se resuelve en esta carpeta, el usuario podrá escribir una importación sin importar dónde se encuentre en el árbol de carpetas, siempre como un slash components slash vuto.vue, y el complemento de alias lo transpilará a la ubicación correcta.

Luego tenemos los complementos previos del usuario. Este es el primer lote de complementos del usuario. En Vite, hay una única lista de complementos, pero una bandera obligatoria permite a los usuarios decidir dónde se debe insertar este complemento en el pipeline. El complemento de resolución de Vite implementa la lógica de resolución para PATH, como la resolución de paquetes. El complemento de CSS de Vite nos brinda soporte para módulos CSS, PostCSS y otros preprocesadores de CSS. El complemento de ES Build de Vite transpila las fuentes CSS, eliminando los tipos y compilando CSS utilizando ES Build. Luego tenemos algunos complementos de Vite JSON, Vite WASM y Vite Worker, que son complementos de características que nos brindan soporte para patrones comunes, como importar un archivo JSON como un objeto.

Aquí podemos ver que incluso podemos importar un campo raíz del JSON como un nombre en la exportación, y esto ayuda con el tree shaking. Luego tenemos el complemento de activos de Vite, que implementa el manejo de activos importados. Por ejemplo, se puede importar una imagen y se obtiene una URL que se puede usar tal cual en el código de la aplicación, y Vite codificará la imagen como una URL base 64 por debajo de un límite de tamaño de celda configurable como una optimización de fábrica. Luego tenemos el complemento de CSS POST de Vite, que utiliza ES Build para minimizar CSS, y desempeña un papel en la transformación de la importación dinámica, por lo que su CSS relacionado se precarga cuando se solicita el fragmento js.async correspondiente. Como dijimos, una importación dinámica se instrumenta, por lo que los activos relacionados se precargan cuando se va a importar, y esto también es una optimización que se obtiene de fábrica. El complemento de HTML construido por VIT procesa los puntos de entrada HTML, reemplazando los scripts y las hojas de estilo con su versión de paquete y optimizada, como vimos antes. Hay algunos complementos que permiten el manejo de importaciones dinámicas importMetaURL e importaciones globales. Por ejemplo, importMetaGlobe nos permite importar un conjunto de módulos desde el sistema de archivos utilizando un patrón de globo, y esta sintaxis es compatible con el complemento de análisis de importación de VIT build, que se expande como una lista de importaciones regulares. Por lo tanto, podemos ver que aquí estamos solicitando todos los archivos shales en la carpeta dir y esto será transformado por el complemento de análisis de importación de construcción en una lista expandida con cada importación dinámica para todos los archivos que están en esa carpeta en el momento de la construcción. El complemento de transpilación de vid ESbuild aprovecha ESbuild para compilar shales a los objetivos configurados y minimizar el código del paquete. Hace algunas versiones menores, vid lo usaba tarsier para la minimización de forma predeterminada, pero una vez que la minimización de ESbuild maduró lo suficiente, se cambió como predeterminado, acelerando en gran medida el proceso de construcción. Y esto también es importante en la filosofía de vid porque vid utilizará la mejor herramienta disponible en ese momento y cambiará las herramientas internas a medida que evolucione el ecosistema.

Los complementos de vid manifest y vid SSR manifest permiten a los proyectos generar metadatos sobre los fragmentos generados que se pueden utilizar para integrar vid con otras herramientas, como rails o Laravel. Por ejemplo, el complemento de vid manifest genera un archivo manifest.json que contiene un mapeo de nombres de archivo de activos no hash a sus versiones hash, que luego puede ser utilizado por un marco de servidor para renderizar el activo correcto.

enlaces. Y este es el pipeline completo de complementos de construcción y puedes ver que hay bastantes de ellos. Si usamos rollup simple, tendremos que configurarlo con un pipeline equivalente si queremos admitir todas las características y optimización que vid ofrece. Podemos ver que incluso sin el servidor VDev en la mesa, vid tiene un gran valor como una herramienta de construcción completa y con opiniones porque obtienes esto de forma predeterminada. Así que vid también es un conjunto de herramientas extensible para crear marcos de trabajo modernos. Hay una API de JavaScript completa. Como vimos, hay un ciclo de retroalimentación instantánea utilizando dev y módulos empaquetados, soporte listo para usar para TS, CSS, post CSS y más. Entonces los marcos de trabajo no necesitan preocuparse por cómo admitir esto. Hay un sistema de complementos flexible que se conecta y mejora el ecosistema. Y esto también permite a los marcos de trabajo utilizar los complementos en los que está trabajando todo el ecosistema y también desarrollar los suyos propios para sus necesidades específicas. Hay una API de SSR compartida de bajo nivel que pueden compartir, y soporte listo para usar para construcción optimizada como vimos utilizando rollup. Y si es necesario, puede haber soporte para todos los navegadores utilizando

VJ como complemento heredado. Así que esto terminó en una explosión de proyectos que utilizan VIT. En primer lugar, el equipo central de VIT mantiene complementos para Vue y React, y los equipos de Svelte, Preact, Solid, Marco, entre otros marcos de interfaz de usuario, proporcionan complementos oficiales de Polish para cada uno de ellos. También existe un vibrante ecosistema de complementos, y se mantiene una lista completa en awesome-vit. Puedes obtener complementos para BWA, o incluso para ayudar en la depuración, y una gran parte del éxito de VIT se debe a que es elegido por marcos de aplicaciones modernas como SvelteKit, Knux 3, Hydrogen, Astro, Solid Start, solo por nombrar algunos. Y eso es todo. Puedes seguir profundizando en cómo se implementa Vite Build en patak.dev.vite.build.html y tienes la documentación en vites.dev o el repositorio de vitecore y el chat de Discord en chat.vites.dev y el handle de Twitter es vites.js también. Y si estás interesado en herramientas de construcción y DX, deberías participar en la comunidad de Vite y colaborar con nosotros. Tenemos una comunidad muy acogedora y muchos colaboradores trabajando juntos para mejorar ViteCore. Eso es genial. Entonces, la pregunta era si la gente ha participado antes en la comunidad de Vite y sí, parece que hay mucha gente que quiere hacerlo. No hubo respuesta negativa, así que la pregunta es un poco complicada, pero eso es bueno. ¿Te sorprenden los resultados? Sí, vi que habría gente que respondería enviando una PR. Ahora mismo tenemos más de 500 colaboradores en el repositorio de Vite, así que vi que algunos de ellos estarán presentes. Si no lo has hecho, Vite es un proyecto realmente bueno para involucrarse y hay una comunidad muy activa, no solo en el núcleo. Sino también en el propio repositorio de Vite, hay mucha gente revisando las PR y tratando de hacer que las cosas funcionen, así que... ¿Tienes algún problema bueno para comenzar o, supongo que sí, usas etiquetas estándar para tus problemas? Sí, no usamos mucho la etiqueta good for issue en particular, tenemos muchos problemas. Vite explotó en el último año, así que llegamos a tener 770 problemas en realidad y ahora estamos tratando de cerrar tantos como sea posible. Hay uno de los colaboradores que está haciendo un trabajo increíble allí, así que lo mejor es involucrarse en la clasificación, revisar cualquier problema y verificar si todavía es relevante, si es un problema de configuración y luego adentrarse en el código base. Creo que la mayoría de los problemas son buenos para los colaboradores. ¿Cuántos de ustedes forman parte del equipo central? Ahora mismo, alrededor de 7 u 8 personas están en el equipo central, pero también tenemos a Vite impulsado por todos los marcos que lo utilizan, como Sveltefox, Astrofox, todas las personas en el ecosistema de Vue, también hay este marco Hydrogen en el ecosistema de React que también lo está impulsando. Así que en realidad tenemos muchos colaboradores en todo el ecosistema. Es enorme. Entonces, para que se apruebe una PR, ¿necesitas la aprobación de un conjunto particular de colaboradores, como colaboradores principales? Lo que hacemos es que, para las PR corregidas, necesitamos dos aprobaciones de los colaboradores principales. Seguimos adelante con ellas. Tenemos algunas personas en el ecosistema que son expertas en algunas partes, como SSR u otras partes, y contamos su voto como una aprobación, incluso si no son miembros del equipo central. Y luego, para las nuevas características, generalmente nos reunimos cada dos semanas y reunimos a todo el equipo central, con todos incluidos, y decidimos qué nuevas características se incluirán o no. Matías, ¿dónde necesitas más ayuda para impulsar este proyecto? ¿Dónde te gustaría ver que las personas contribuyan? Hay documentación, hay PR como dijiste. Creo que donde necesitamos ayuda es en la clasificación, y esa es una muy buena manera de involucrarse, como discutimos antes. Tenemos muchos problemas nuevos y también, tal vez, si tienes experiencia con ello, unirse a la comunidad y ayudar a los demás es una de las mejores cosas que puedes hacer. De acuerdo.

También es una muy buena manera de involucrarse. No olvides que puedes hacerle preguntas a Matias. Él estará en la sala de oradores. ¿Tenemos alguna pregunta en este momento de la audiencia? Vamos a verificar.

De acuerdo, puedes unirte a Matias en cualquier momento en este momento. Oh, hay una de Rens for the win. ¿Qué tan fácil es usar un complemento personalizado de Rollup con Vite? Es bastante fácil. La API de complementos de Vite es compatible, en su mayor parte, con Rollup. Es una extensión de Vite, por lo que la mayoría de los complementos en el ecosistema de Rollup funcionan de manera predeterminada en Vite. Hay algunos hooks muy específicos que no se pueden usar, pero esto es bastante raro, por lo que debería funcionar de manera predeterminada.

Jay Reed pregunta qué tan difícil es pasar de Create React App a Vite, y si hay un proceso documentado. Hay un proyecto llamado Webpack to Vite, que es bastante interesante porque lo ejecutas en tu proyecto y en realidad hace la conversión, o intenta hacer la conversión automáticamente, por lo que creo que también es una muy buena manera si no funciona porque estás haciendo algo muy personalizado, puedes ver todos los pasos. Pero principalmente se trata de eliminar, por ejemplo, Webpack y agregar Vite y cambiar algunas opciones de configuración, no es un proceso muy difícil.

De acuerdo, eso suena bien... ¿sí? ¿Apuntas a la simplicidad? Eso es lo que parece, que estás tratando de hacer que sea simple de adoptar. Sí, una de las cosas que Vite tiene, en términos de filosofía, es tratar de atender a un objetivo más pequeño, digamos, que lo que Webpack estaba haciendo, que era como, puedes hacer lo que quieras con Webpack. Pero Vite se enfocó más en, okay, hagamos lo mejor que podamos para una aplicación web, y tratemos de obtener buenos valores predeterminados para ese caso de uso. La gente está empezando a usarlo para otras cosas, como Electron, pero eso no es la competencia principal. Por lo general, en el núcleo tratamos de mantenerlo pequeño y trasladar la mayor parte de esa complejidad. Afortunadamente, tenemos el sistema de complementos que es bastante flexible. Así que la mayoría de las veces no necesitamos rechazar algo, solo necesitamos decir, mira, puedes hacer lo mismo con el complemento. Así que tratamos de mantener el núcleo pequeño.

Excelente. Y realmente me encanta la historia de la herramienta, pero también me encanta la historia de los desarrolladores detrás de ella. Cuéntanos sobre tu historia como desarrollador. ¿Eres autodidacta? ¿Viene de un fondo en ciencias de la computación? ¿Cómo fue tu viaje hasta este momento? Estudié ingeniería electrónica, pero terminé más en el lado de la programación. Hice algo de C++ al principio. Mis experiencias iniciales de código abierto fueron con algunas bibliotecas de C++. Y luego fui a otros proyectos, como empecé a hacer mucho web que no era de código abierto, pero empecé a trabajar con algunos motores gráficos, como mover cosas del servidor al cliente. Y hace, creo, como dos años, como comenzando por un proyecto de código abierto que estaba usando Vite y usando Vue 3, comenzamos a involucrarnos

más involucrado. Y esto fue justo cuando Vite estaba comenzando a despegar. Así que me uní a Vite en el momento adecuado, cuando había muchas necesidades de colaboración. Esa es mi historia cuando empecé. Pero ¿ya estabas trabajando en sistemas de compilación antes, o pasaste del desarrollo frontend? Estaba haciendo, como, desarrollo web en general, durante muchos años, mi trabajo era, como, en realidad, hacer un motor gráfico, como una especie de experiencia en línea de Corel en la web. Pero estaba haciendo más desarrollo web, no herramientas de compilación en particular.

De acuerdo. ¿Y qué es lo que más te gusta de las herramientas en general? En particular, sobre Vite, creo que lo que realmente me atrajo fue la retroalimentación instantánea. Esta idea de ver tus cambios mientras modificas cosas. Por ejemplo, si tienes un control deslizante para cambiar un color o algo así, realmente puedes tener la misma experiencia que tienes con las herramientas de desarrollo. Puedes tenerlo directamente en tu código real, ¿no? Y esa retroalimentación instantánea realmente permite cierto tipo de exploración y programación mediante la exploración de las opciones que tienes. Y creo que eso es bastante interesante y lo que me atrajo allí.

Sí, creo que este es un momento increíble para los desarrolladores web. Para aquellos de nosotros que hemos estado haciendo desarrollo web durante muchos años, el estado actual es increíble. Realmente no se puede comparar. Es asombroso. Realmente se centra en la experiencia de desarrollo y espero que siga así. ¿Dónde ves a Vite el próximo año? ¿Hacia dónde se dirige? ¿Qué quieres lograr? Creo que en el núcleo, la consolidación, seguir haciéndolo más sólido y tenemos algunas características interesantes, como mejorar HTML, estamos trabajando en ello, habrá un mapa de origen de CSS que antes no era posible. Hay algunas cosas, pero principalmente consolidación, donde veo mucha innovación es en los proyectos que utilizan Vite, por lo que el ecosistema está creciendo mucho y, al igual que Hydrogen, hay muchos, muchos proyectos que ahora están utilizando Vite y me doy cuenta de que este año se trata de eso, de los frameworks que lo utilizan. ¿Los equipos principales de los frameworks se ponen en contacto contigo para, sí, intentar construir sobre él, ¿verdad? Sí, sí, y generalmente necesitan muchas de las características, muchas de las nuevas características en Vite han sido porque los frameworks, incluso los mantenedores, realmente las necesitaban, por lo que ellos proponen, incluso hacen las solicitudes de extracción y trabajan con nosotros. De acuerdo, muchas gracias, Matthias. Nuevamente, a todos los asistentes, pueden seguir haciéndote preguntas en Discord, devops-talk-q&a, y sí, le devuelvo la palabra a Anuradha. ¡Gracias!