Desde que JavaScript se convirtió en un lenguaje para escribir aplicaciones, las herramientas de construcción y especialmente los bundlers han estado presentes. Resuelven la discrepancia entre escribir código que sea fácil de mantener y escribir código que se cargue eficientemente en un navegador. Pero hay ventajas en el empaquetamiento del código JavaScript que van más allá del navegador, desde funciones en la nube hasta servidores y herramientas de línea de comandos.
RollupJS es especial porque siempre fue diseñado desde cero para ser un bundler de propósito general en lugar de una herramienta específica para el frontend. En esta charla, veremos de qué manera otros escenarios pueden beneficiarse del empaquetamiento. Pero lo más importante, te mostraré cómo RollupJS no solo genera una salida superior en muchas situaciones, sino lo fácil que es adaptar su salida a requisitos personalizados y escenarios no estándar. Veremos cómo parchear código, simular y reemplazar dependencias, inyectar elegantemente información de construcción y controlar la generación de fragmentos al dividir el código, todo con solo unas pocas líneas de código.
This talk has been presented at DevOps.js Conf 2021, check out the latest edition of this JavaScript Conference.
FAQ
Rollup ayuda a optimizar el tiempo de carga y el tamaño del código al evitar la 'cascada' de solicitudes de red y al empaquetar todos los archivos necesarios en uno solo. También es agnóstico al entorno objetivo, lo que permite su uso en diversos contextos como el navegador o Node.js, y ofrece una buena eliminación de código muerto.
El empaquetado puede reducir significativamente los tiempos de carga al minimizar el número de solicitudes de red necesarias. Por ejemplo, una aplicación probada mostró un tiempo de carga de 18.3 segundos sin empaquetar, mientras que con empaquetado el tiempo se redujo a 7.5 segundos.
Un complemento en Rollup es un módulo que introduce funcionalidades adicionales. Estos pueden manipular o transformar el código durante el proceso de empaquetado, como cambiar configuraciones de desarrollo a producción o eliminar código específico no deseado en la compilación final.
Rollup soporta varios formatos de salida incluyendo CommonJS, módulos ES, y otros como AMD y módulos ES. El formato de módulos ES es especialmente relevante ya que es el formato nativo de Rollup.
Rollup es beneficioso en escenarios donde el tiempo de inicio rápido es crucial, como en funciones Cloud y herramientas de línea de comandos. Esto se debe a que la optimización del empaquetado reduce tanto el tamaño del código como el tiempo necesarios para que la aplicación se vuelva operativa.
Un gancho en Rollup es una función que permite a los complementos interactuar con el proceso de empaquetado en diferentes etapas. Por ejemplo, el gancho de carga manipula cómo se carga un módulo, mientras que el gancho de transformación permite modificar el código antes de su empaquetado final.
Una estrategia es la eliminación de archivos innecesarios en los módulos, como tipos de TypeScript y documentación, que no son necesarios en producción. Rollup también puede compilar todos los archivos necesarios en uno solo, reduciendo el tamaño total y mejorando el tiempo de inicio del servidor.
Rollup es único en que está diseñado desde cero para ser agnóstico al entorno y admite una personalización extensa mediante complementos. Aunque otras herramientas pueden ser efectivas, Rollup es especialmente útil para bibliotecas y aplicaciones que requieren configuraciones de empaquetado específicas.
Esta charla explora la optimización del código JavaScript utilizando Rollup, mostrando ejemplos de tiempos de carga mejorados y tamaño reducido del servidor. Se adentra en la personalización de Rollup y el desarrollo de complementos, demostrando cómo escribir complementos y eliminar código utilizando hooks. La charla también cubre la carga de código de módulo, el control avanzado de código y la importación/emisión de archivos con Rollup. Además, destaca la adopción del sistema de complementos de Rollup por parte de otras herramientas e introduce un terminal hecho a medida utilizado en la presentación.
1. Introducción a la optimización del código JavaScript
Short description:
Hola y gracias por sintonizar mi sesión sobre cómo mejorar tu código JavaScript generado utilizando Rollup. Quiero abordar otra pregunta. ¿Por qué estamos utilizando todos estos complejos pipelines de construcción y agregando todas estas cosas alrededor de nuestro código JavaScript? Para darte dos razones, te mostraré algunos ejemplos. El primer ejemplo es una implementación de Scrum Poker de código abierto y pequeña. Se puede ejecutar durante el desarrollo sin empaquetar, y el tiempo de carga se reduce significativamente con el empaquetado. La diferencia se debe a las solicitudes de red y al efecto de cascada de carga de archivos JavaScript. Ahora consideremos un escenario de servidor con una configuración básica de Apollo server en Docker. El tamaño de la imagen de la imagen alpina de Node 14 es de 116 megabytes.
Hola y gracias por sintonizar mi sesión sobre cómo mejorar tu código JavaScript generado utilizando Rollup. Antes de entrar en esa parte, en realidad, quiero abordar otra pregunta. La pregunta es la pregunta básica de JavaScript. ¿Por qué estamos utilizando todos estos complejos pipelines de construcción y agregando todas estas cosas alrededor de nuestro código JavaScript? Para darte dos razones, te mostraré algunos ejemplos primero.
El primer ejemplo es algo que construimos en nuestra empresa. Es de código abierto, una pequeña implementación de Scrum Poker. Puedes probarlo si quieres. La parte importante de esto, por qué lo elegí, es porque con esta aplicación es posible ejecutarla durante el desarrollo sin empaquetar. Hice algunas mediciones simulando una conexión de red muy lenta en un teléfono móvil pequeño. Los tiempos que obtuve sin empaquetar fueron alrededor de 18.3 segundos para cargar, pero con el empaquetado, tarda siete segundos y medio. Ahora, quiero decir que el único cambio entre esos números fue el empaquetado. No hay mucho menos código en el lado derecho. No hay compresión, no hay minificación. ¿Por qué es eso, en realidad? ¿Por qué hay esta diferencia en los números? La diferencia se puede ver en estas dos imágenes. Son estos escalones verdes aquí, o generalmente se les llama cascada. Lo que está sucediendo es que comienza con el primer archivo JavaScript y luego ve que hay algunas importaciones en el archivo. Una vez que descubre esas importaciones, envía la solicitud de red para obtener más archivos. Necesita cargar esos archivos, pasar esos archivos y descubrir algunas importaciones más, y así sucesivamente. Entre todos esos pasos, básicamente hay solicitudes de red de ida y vuelta, y esto se acumula. Por supuesto, lo que hace el empaquetado es evitar la cascada.
Ahora la pregunta es, bueno, esto es una aplicación web, sé lo que estamos haciendo aquí. ¿Qué pasa con nuestras situaciones? Digamos que estamos mirando un servidor. Esta vez, tengo un servidor Apollo muy básico configurado aquí, tomado del sitio web. Esta vez, no te daré números inventados. Esta vez, lo haremos en vivo. Voy a construir un servidor en Docker. Para darte un punto de referencia, tengo una pequeña terminal aquí conectada que está ejecutando comandos en mi máquina. Vamos a construir una imagen alpina de Node 14.
2. Configuración de Dockerfile y Reducción del Tamaño del Servidor
Short description:
Aquí tenemos dos archivos Docker preparados. El primero es una configuración tradicional, copiando archivos de paquete, instalando dependencias de producción y copiando el archivo del servidor. El segundo Dockerfile utiliza rollup para reducir el tamaño del servidor de 18MB a 4MB eliminando archivos innecesarios en los módulos de nodo. Esto reduce el tiempo de inicio y es beneficioso para las Cloud Functions y las herramientas de línea de comandos.
Imagen de Docker. Esto es 116 megabytes. Tal vez quieras recordar este número. Aquí tenemos dos archivos Docker preparados. El primero que voy a ejecutar es una configuración muy tradicional. Lo que estamos haciendo es copiar los archivos de paquete. Estamos instalando las dependencias de producción. Estamos copiando el archivo del servidor. Este es el archivo. Hay un pequeño envoltorio aquí. Este envoltorio está ahí solo porque inicia un temporizador pequeño. El temporizador se detiene una vez que el servidor dice que está completamente funcional. Eso es solo para las mediciones. Estoy ejecutando un comando que también iniciará inmediatamente el servidor para obtener algún tiempo. Lo que estoy haciendo aquí también es copiar todo a otra imagen, solo la carpeta que acabamos de crear. La razón es que durante este año, se crean muchas cachés, y esto ahorra otros dos o tres megabytes. Estoy haciendo esto ahora. Esto solo tomará un momento porque todo está en caché en este momento. Lo primero que ves, recuerdas, eran 160 megabytes antes, ahora son 134 megabytes, por lo que básicamente es un servidor de 18 megabytes. El tiempo de inicio fue casi de 300 milisegundos.Ahora tengo aquí un segundo Dockerfile, que es este. Entonces, lo que hace este es básicamente ejecutar rollup aquí, tomando el servidor como punto de entrada y siendo travieso, sobrescribiéndolo nuevamente, y hay tres complementos, Node.resolve, CommonJS y JSON, que son necesarios para la compatibilidad con nodo y estamos creando un archivo CommonJS, y eso es todo. Luego, básicamente copiamos el artefacto creado, y cuando hago esto, veamos cuáles son los números ahora. Verás, son 120 megabytes, por lo que el servidor de 18 megabytes se convirtió en un servidor de cuatro megabytes.Entonces, ¿por qué es eso? Eso se debe a que realmente hay muchas cosas innecesarias en tus módulos de nodo. Estos son los tipos de TypeScript, estos son archivos de prueba, documentación, quién sabe qué utilidades innecesarias. Entonces, esto tal vez no sea tan relevante si dices, okay, 130 versus 120, pero esta fue una configuración realmente básica. Entonces, esto sigue sumando, cuanto más grande se vuelve tu servidor, y por supuesto, el tiempo de inicio fue de 171 milisegundos, por lo que es casi la mitad del tiempo de inicio. Y esto es, nuevamente, la misma razón que viste antes. Estás reduciendo el tiempo de cascada. Entonces, vemos que esto reduce el tamaño y el tiempo de inicio, por lo que los servidores tal vez no sean tan importantes, pero las Cloud Functions definitivamente sí lo son. Esas Cloud Functions realmente necesitan un tiempo de inicio rápido o también las herramientas de línea de comandos. Entonces, otra pregunta, ¿por qué querrías usar rollup para
3. Personalización de Rollup y Desarrollo de Plugins
Short description:
Rollup está diseñado para ser agnóstico al entorno objetivo, lo que permite la personalización. Funciona bien para el navegador de forma predeterminada, pero se necesitan complementos para otros entornos. El formato nativo de Rollup, los módulos ES, permite un empaquetado eficiente para bibliotecas. Es fácil tomar el control del código con Rollup. En el primer ejemplo, importamos información de un archivo y queremos personalizarlo durante la producción. Para lograr esto, escribimos un complemento y usamos el gancho de carga.
¿Por qué esto? Así que hay muy buenas opciones alternativas. No voy a decir que sean malas porque no lo son. Lo especial de Rollup es que está diseñado desde cero para ser agnóstico al entorno objetivo. Por lo tanto, puedes personalizarlo de la manera que desees. Puedes construir para el navegador, para Node, para demostraciones, lo que quieras. Esto también significa que generalmente necesitas agregar algunos complementos para personalizarlo. Por defecto, funciona bastante bien para el navegador, pero definitivamente necesitas algunos complementos para Node. También obtienes una buena selección de formatos de salida como CommonJS, módulos ES y varios otros formatos como AMD y módulos ES. El formato de módulos ES es especial porque es el formato nativo de Rollup, lo que significa que si empaquetas a módulos ES y tomas la salida y la vuelves a empaquetar, simplemente no cambia más. No se vuelve más grande, lo que significa que Rollup se utiliza mucho para bibliotecas. Porque aquí, no quieres tener las dependencias de tiempo de ejecución todo el tiempo. Y también tenemos una muy buena eliminación de código muerto, aunque no fue importante en los ejemplos anteriores.
Entonces, queremos hacer cosas con nuestro código. Sabemos por qué queremos empaquetar, la pregunta es, por supuesto, cómo. Y lo que veo aquí con frecuencia en Rollup es que a veces, aunque hay complementos muy buenos, básicamente quieres tomar las cosas en tus propias manos. Y definitivamente puedes hacerlo porque es muy fácil. Si no sabes qué hacer durante la charla, puedes unirte en este momento porque esto se está transmitiendo en vivo aquí. Puedes ir a lucastagger.github.io/DevOps-JS si quieres comenzar, la diapositiva actual es la número siete. Y si no eres lo suficientemente rápido para escribir esto, la URL estará en la parte superior de las próximas dos diapositivas. Así que empecemos aquí. El primer ejemplo, aquí está el que estaba hablando, el primer ejemplo que quiero mostrarte es una situación muy común. Tienes un archivo principal aquí, que está importando información de un archivo build.js. Y en este caso, solo está importando una cadena que nos dice: `Esto es una compilación de desarrollo`. Pero podría haber más información aquí. Digamos que podría haber un servidor diferente para la producción o esto podría ser localhost durante el desarrollo, pero no sé qué servidor durante la producción u otra información. Y lo que quieres hacer es básicamente mantener la configuración sin cambios durante el desarrollo, pero durante la producción, queremos cambiar esta información. Así que vamos a escribir un complemento. ¿Cómo lo haces? Y como puedes ver, mi configuración está ejecutando Rollup en vivo mientras escribo, la salida está aquí en la esquina inferior derecha. Los complementos son una matriz de objetos. Y un complemento expone varios ganchos a los que Rollup puede engancharse. Y el gancho que vamos a usar para el primer ejemplo es el gancho de carga. El gancho de carga recibe un ID, que es un identificador del archivo, y esto generalmente es
4. Escribiendo un Plugin para ID slash build.js
Short description:
Si el ID es slash build.js, queremos devolver algo más, específicamente export const type equals production. Así de simple es escribir un plugin.
la ruta del archivo en el disco. Entonces lo que queremos hacer es, si el ID es slash build.js, entonces queremos devolver algo más. Queremos devolver, así que necesita ser, exportar algo, exportar const type equals, y tal vez usar una nueva línea para que puedas seguir leyendo lo que estoy escribiendo. Sí. Production. Y aquí estamos, acabamos de escribir nuestro primer plugin. Ahora en la salida, es const type equals production. Y así de simple es. Por cierto, si estás siguiendo esto en vivo, nuevamente, las URL están aquí arriba, puedes hacer clic en el botón aquí abajo a la izquierda para mostrarte a dónde queremos ir.
5. Eliminando código con el gancho de transformación
Short description:
En este ejemplo, estamos utilizando el gancho de transformación para eliminar líneas de código específicas basadas en una sintaxis personalizada. Al utilizar una expresión regular y el método replace, podemos eliminar fácilmente las líneas seleccionadas. Esta eliminación no es solo estética; está integrada en el análisis de Rollup y permite una eliminación eficiente de árbol. Además, discutimos brevemente los ganchos de carga y transformación y su papel en el ciclo de vida del módulo.
De acuerdo. Así que esto fue la carga de cosas. Vamos a otro ejemplo. Esta vez vamos a inventar una sintaxis que queremos usar. Digamos que queremos tener comprobaciones especiales de registro y demás durante el desarrollo que queremos eliminar durante la producción. La sintaxis que estamos inventando aquí es que cada vez que precedemos una línea con este comentario, remove, queremos eliminar todo hasta el final de la línea. El gancho que estamos utilizando esta vez es el gancho de transformación. El gancho de transformación en realidad tiene dos argumentos. El primer argumento es el código del módulo. El segundo sería el ID, pero nuestra transformación actual no depende del módulo individual. ¿Cómo se hace esto? Lo más fácil sería usar una expresión regular. Simplemente vamos a usar code, replace, y replace puede tener una expresión regular como su primer argumento, que va a ser una expresión global. Queremos reemplazar todas las ocurrencias con una cadena vacía. ¿Qué necesitamos poner aquí? Es slash star remove star slash. Ves, ya eliminé mi comentario, pero eso no es lo que quería. Queremos eliminar hasta el final de la línea, así que necesitamos varios caracteres que no sean un salto de línea. Esto es eso, hasta el salto de línea. Y aquí vamos. Acabamos de eliminar la segunda línea. Podría copiar esto a la primera línea. También sería eliminada. Y también ten en cuenta que esto no es solo una eliminación estética de código. Esto está completamente integrado en el análisis de Rollup. Entonces, si digo que tengo una constante foo que también estoy incluyendo aquí en el registro y ahora estoy agregando el comentario aquí, foo también será reconocido como no utilizado y la eliminación de árbol simplemente se deshará de esto en nuestra compilación. Hasta ahora hemos visto dos ganchos, carga y transformación. Para darte una idea de cómo esto encaja en el panorama general, echemos un vistazo de alto nivel al ciclo de vida de un módulo. Entonces, la situación que tenemos aquí, tenemos un módulo slash main.js y solo contiene por ahora una declaración de importación. Entonces, qué hace Rollup con este código? Lo primero que hace es tomar esta declaración de importación y pasarla al gancho de resolución de ID. No has visto este aún. Lo usaremos en el siguiente
6. Gancho de Resolución de ID e Importación de Origen
Short description:
El gancho de resolución de ID se llama en cada complemento que lo implementa, y el segundo complemento puede proporcionar un origen de importación específico para un ID dado. El algoritmo predeterminado agrega la fuente relativa al directorio del importador.
ejemplo. Y el gancho de resolución de ID tiene dos argumentos. El primero es el origen de importación exactamente como está escrito aquí. Y el segundo es el ID del módulo importador. Ahora, este gancho se llama en cada complemento que lo implementa hasta que uno de los complementos lo responde. Entonces, en este caso, digamos que el segundo complemento dice: oh, sé lo que significa. Si alguien desde slash major imports dot slash foo, entonces quieren slash foo.js. Lo cual no es sorprendente. Y en realidad, algo que el núcleo también habría hecho porque hay un algoritmo predeterminado que simplemente hace eso. Toma el directorio del importador y agrega la fuente relativa aquí.
7. Carga y Transformación de Código de Módulo
Short description:
En el gancho de carga, obtenemos el código del módulo pasando el ID descubierto. El gancho de carga verifica cada complemento y el primero que lo implementa y devuelve algo nos proporciona el código. El gancho de transformación permite a los complementos realizar transformaciones de código. Podemos reemplazar argumentos o inyectar importaciones. Otro ejemplo es cambiar la resolución de archivos usando la función de resolución en el contexto. Devuelve un objeto con el ID resuelto.
De acuerdo. Entonces necesitamos obtener el código del módulo y esto se hace mediante el gancho de carga. Así que el ID que acabamos de descubrir, lo estamos pasando ahora al gancho de carga. El gancho de carga verificará nuevamente cada uno de los complementos. Y el primer complemento que lo implemente y también devuelva algo será el que nos proporcione el código. Y dado que en este ejemplo, ningún complemento lo implementa, tenemos una implementación predeterminada, que asume que esta es la ruta a un archivo e intenta cargarlo desde el sistema de archivos. Así que ahora estamos obteniendo este código aquí. Y luego está el gancho de transformación. Ahora que básicamente tenemos el primer vistazo del código. Cada complemento tiene la oportunidad de hacer algunas transformaciones en el código. Esto está destinado a complementos como Babel, para transformar código, pero cualquier otra transformación de código es posible. Nuevamente, tenemos dos parámetros, el código y el ID, y pasa por todos los complementos. El primero podría reemplazar el argumento aquí. El segundo podría inyectar una importación. Y ahora que tenemos otra importación, básicamente comienza desde el principio y el ciclo continúa. Estos no son todos los ganchos de complementos que hemos inscrito. En realidad, hay algunos más, pero estos serán los que probablemente quieras usar más.
Entonces ahora hagamos otro ejemplo. Esta vez estamos revisando nuestro primer ejemplo. Queremos reemplazar alguna información de tiempo de compilación con información de producción. Pero esta vez queremos tener dos archivos que ya existen en el disco. Así que podríamos usar nuevamente el gancho de carga y simplemente leer este archivo en el gancho de carga, pero tal vez sería más agradable cambiar la resolución del archivo. Así que cada vez que se importe este archivo, queremos importar realmente este archivo. Debería ser algo como si el ID es igual a log-dev.js, entonces devuelve log-prod.js. Bueno, esto, por supuesto, no funciona porque no tenemos el ID. Solo tenemos la fuente y el importador. Entonces lo que nos gustaría saber es, Rollup, ¿cómo resolverías esta fuente y este importador a un ID? Y para eso tenemos funciones de contexto. Así que cada gancho de complemento se llama con un contexto especial this que contiene varias funciones. Esta vez queremos usar esta resolución. Y como esta es una función asíncrona, queremos esperarla y devolverá
8. Control Avanzado de Código y Paquetes de Auto-Referencia
Short description:
Ahora llevémoslo al siguiente nivel al eliminar por completo la dependencia del sistema de archivos. Podemos reemplazar información usando un archivo virtual llamado 'build'. Resolvemos el ID de construcción y manejamos el error de falta de sistema de archivos. Finalmente, exploramos el concepto de un paquete de auto-referencia que conoce sus propios archivos.
un objeto con una propiedad de ID. De acuerdo. Ahora no voy a cerrar esto porque tan pronto como escriba la pieza de cierre del paréntesis, esto será un bucle infinito porque llamar a esta resolución en realidad llamará a todos los complementos a menos que esté pasando un argumento especial, que es omitir self dos. Y sí. Y aquí vamos. Entonces la compilación de desarrollo fue esta, la compilación de producción ahora es log a log y ahora está reemplazando este archivo con el otro.
De acuerdo. Otro ejemplo. Entonces llevar esto al siguiente nivel significa que realmente podemos completamente sin el sistema de archivos. Hasta ahora, los ID eran como partes de archivos, pero no estás limitado a esto. Entonces, para la última versión de esto, vamos a reemplazar información. Simplemente, vamos a usar un archivo completamente virtual. Lo llamamos build sin nada alrededor de esto. Entonces ahora, usando lo que acabamos de aprender, realmente podemos necesitamos hacer dos cosas. Ya está advirtiendo aquí que no se puede resolver build. Entonces, en primer lugar, necesitamos resolverlo y resolverlo es simplemente decirle a Rollup, de acuerdo, está totalmente bien. Esto es un ID. Entonces lo que estamos haciendo es simplemente si la fuente es igual a build, entonces simplemente devolver la fuente nuevamente. De acuerdo. Y el error cambió. Ahora esta vez está cargando esto, y como estamos usando el navegador construido aquí en la presentación, se queja de la falta de sistema de archivos. Entonces estamos haciendo lo mismo aquí. Si el ID es igual a build, entonces simplemente devolver export. Oh, de acuerdo. Nueva línea. Y es igual a prod. Y aquí estamos. Nuestro primer módulo completamente virtual. Y como último ejemplo de lo que puedes hacer para tener un control total de tu código, solucionar problemas, y realizar cualquier tipo de transformación, como esta vez queremos hacer un paquete de auto-referencia. Entonces queremos un paquete que sepa qué archivos están en el paquete en el código JavaScript.
9. Importación y Emisión de Archivos con Rollup
Short description:
Estamos importando algo desde un archivo, desde un archivo, slash build.js, y lo estamos utilizando como una importación externa. Se generan dos archivos debido a la declaración de importación dinámica, lo que indica carga perezosa. Emitimos el archivo utilizando el ayudante de contexto 'emit file' con el tipo 'asset', el nombre de archivo 'build.js' y una fuente vacía. El paquete generado muestra los nombres y tamaños de los archivos. Hay mucho más que puedes hacer con Rollup, incluyendo construir tus propios complementos o usar herramientas de alto nivel como Stencil, VEET y WMR. Para bibliotecas, considera MicroBundle o TSDex. Gracias por acompañarme y siéntete libre de explorar el sitio web para ver ejemplos.
Y estamos usando un truco aquí. Así que estamos importando algo desde un archivo, desde un archivo, slash build.js, y en realidad no estamos implementando este archivo en este momento, sino que lo estamos utilizando para indicar que es externo. Y ya puedes ver, simplemente se muestra como una importación aquí en los archivos resultantes. Además, puedes ver que hay dos archivos generados. La razón es la declaración de importación dinámica aquí, que Rollup interpreta como que quieres tener una carga perezosa aquí, por lo que se creará un fragmento diferente solo para esto. Y, bueno, lo que estamos haciendo aquí es emitir este archivo. Entonces hay un ayudante de contexto, emit file, que te permite agregar archivos al paquete. Y emit file tiene un tipo. El tipo es asset. También podrías usar chunk, pero eso tiene algunas limitaciones en cómo se puede usar, por lo que asset es generalmente lo que quieres para archivos arbitrarios. Necesitamos un nombre de archivo. El nombre de archivo debe ser build.js, y necesitamos alguna fuente. Y ahora en realidad hemos creado un vacío porque el tiempo se está agotando, simplemente estamos usando el atajo aquí. Entonces lo que esto hace básicamente es tomar el objeto bundle, llegas al gancho generate bundle, y simplemente enumera los nombres y el tamaño del archivo. Así que ahora main.js tiene 90 bytes y este tiene 30 bytes, y si cambio algo aquí, puedes ver el número cambiando en tiempo real. Así que ahora son 36 bytes y concluyendo la charla ahora. Realmente hay mucho más que puedes hacer. Así que recomiendo que eches un vistazo al sitio web de Rollup que te dice cómo construir tus propios complementos. Y en realidad, si no quieres seguir ese camino, también hay algunas herramientas de alto nivel construidas alrededor de Rollup. Solo para mencionar algunas, está Stencil para componentes web, VEET, que proviene del ecosistema de VUE y es una herramienta de desarrollo muy buena sin empaquetar durante el desarrollo y con un paso de Rollup preconstruido. Y WMR es muy similar de la comunidad de Preact. Y para bibliotecas, puedo recomendar que eches un vistazo a MicroBundle, que también es más del universo de Preact para bibliotecas de configuración cero, o TSDex para bibliotecas de TypeScript. Y con eso, quiero concluir mi charla. Gracias por acompañarme. Solo recuerda que puedes acceder al sitio web localmente en tu navegador si lo haces, si quieres jugar con ejemplos y muchas gracias.
Hola, sí. Encantado de estar aquí. Excelente tenerte. Así que echemos un vistazo a los resultados de tu pregunta. ¿Cuál es tu experiencia con los complementos de Rollup? Y mientras...
10. Uso de Rollup y Adopción de Complementos
Short description:
Me sorprende especialmente el 11% porque puedes usar Rollup sin complementos, pero eso limita lo que puedes hacer. Tengo grandes esperanzas para el 18% y hice la charla principalmente para el 18%. Hay nuevas herramientas como VEET y WMR que están adoptando el sistema de complementos de Rollup en este momento, por lo que puedes usar tus conocimientos de complementos en otras herramientas. Mucho amor para las opciones más bajas, aunque solo representen el 2% cada una.
Quizás exageré con la cantidad de opciones. Bueno, si hubiera omitido las primeras preguntas, esperaría que la mayoría no haya utilizado Rollup porque es una herramienta de nicho y lo sé. La parte interesante está más abajo, de hecho, me sorprende especialmente el 11% porque puedes usar Rollup sin complementos, pero eso limita lo que puedes hacer. Tengo grandes esperanzas para el 18% y hice la charla principalmente para el 18%, nunca escribí un complemento pero consideraría probarlo porque está surgiendo una especie de capa meta para los complementos de Rollup. Así que hay nuevas herramientas como VEET y WMR que están adoptando el sistema de complementos de Rollup en este momento, por lo que puedes usar tus conocimientos de complementos en otras herramientas. Mucho amor para las opciones más bajas, aunque solo representen el 2% cada una. Debo decir que elegí la opción de Chuck Norris yo mismo y siento que hay muchos otros Chuck Norris en esto.
11. Terminal Autoconstruido y Repositorio de GitHub
Short description:
El terminal utilizado en la presentación es un servidor web autoconstruido y de código abierto. Fue creado por el orador y se puede encontrar en el repositorio de GitHub. El código del terminal es sorprendentemente conciso, cabe en una sola pantalla. El orador se refiere humorísticamente a sí mismo como un sobresaliente.
En esta conferencia, sé que estás aquí. Bueno, vamos a llegar a la pregunta más importante que hemos recibido hasta ahora de la multitud, que es, qué terminal increíble para la presentación. ¿Qué es? Sé la respuesta, pero te permitiré decírmelo. El problema es que empecé un poco temprano a prepararme para la presentación y cuando tienes demasiado tiempo, empiezas a hacer cosas. Así que empecé a escribir un pequeño servidor web y lo puse todo en una presentación de reveal.js. Entonces, básicamente, el terminal es completamente autoconstruido, pero también es de código abierto. Creo que en la última diapositiva de la charla hay, de hecho, la URL del repositorio de GitHub, si no me equivoco, donde puedes ver cómo se hace, es sorprendentemente poco. Así que cabe en una sola pantalla de código, todo el terminal en el lado del backend. Así que eres lo que llaman un sobresaliente. Sí, muy genial. Espero que no haya demasiada gente de mi empresa aquí viendo esto y descubriendo lo que hice con mi tiempo. De acuerdo, así que tenemos muchos asistentes de Node en esta conferencia, o al menos eso asumo. Entonces, supongo que al empaquetar para Node con Rollup, ¿hay alguna característica importante de Node que Rollup no admita y de la que debamos tener en cuenta al usar Rollup? Sí, en realidad hay bastantes cosas a tener en cuenta y eso es bastante importante. Después de la charla, parece que todo es súper simple, haciendo todo más pequeño, pero un problema son los requerimientos dinámicos, este es un problema que todos los empaquetadores tienen. Así que cuando estás escribiendo directamente para Node, básicamente puedes requerir cualquier cosa, concatenar cadenas, construirlas con funciones o lo que sea, e importar un módulo, pero básicamente no puedes hacer esto al empaquetar. También, como process cwd, el directorio de trabajo actual no es un concepto que tengas. Así que este es un problema, hay algunas dependencias que simplemente no funcionan. Tenemos soluciones alternativas para algunas, así que tenemos algunas contribuciones de la comunidad muy buenas, como un resolvedor de nodos simulado en el complemento CommonJS que puedes usar para los casos realmente complicados. Y también actualmente hay mucho trabajo en curso con respecto a las dependencias circulares en Node, porque también dependen mucho de las importaciones en línea. Así que espero resolver esto en los próximos meses de una buena manera, con suerte. Eso es genial. Aprecio mucho tu trabajo en este proyecto. Para aquellos que están a la vanguardia entre nuestros asistentes y tal vez estén empezando a usar Deno, ¿qué complementos necesitas para ponerlo en marcha? Sí, sé que Deno no es utilizado por muchos, pero es muy emocionante porque Deno tiene el concepto de que los módulos de ES son básicamente el sistema de módulos que utilizas, lo cual es realmente nativo para Rollup. Y la otra cosa es que básicamente no tienes el antiguo sistema de módulos de Node en Deno. En Deno utilizas URL para importar tus cosas. Así que todo lo que necesitas para Rollup es básicamente, bueno, necesitas un complemento de TypeScript si quieres escribir TypeScript y necesitas un complemento para esas importaciones de URL. En realidad, hay varios, como Rollup Plugin URL Resolve, que básicamente hace lo que Deno hace por ti en tu paquete. Así que creo que sería una muy buena combinación. Eso es genial. De acuerdo. Solo para recordarte que Lucas se dirigirá a la sala de oradores inmediatamente después de la charla y estará en el chat espacial y también estará disponible en Discord. Así que si tienes más preguntas, definitivamente puedes dejarlas para Lucas en el chat o en el chat espacial para hablar con él. Así que muchas gracias por estar con nosotros, Lucas. Apreciamos mucho que hayas dedicado tiempo a esto y este proyecto es tuyo. Gracias por estar aquí. Sí, gracias a ti también.
NPM workspaces help manage multiple nested packages within a single top-level package, improving since the release of NPM CLI 7.0. You can easily add dependencies to workspaces and handle duplications. Running scripts and orchestration in a monorepo is made easier with NPM workspaces. The npm pkg command is useful for setting and retrieving keys and values from package.json files. NPM workspaces offer benefits compared to Lerna and future plans include better workspace linking and adding missing features.
We will learn how to automate code and testing with GitHub Actions, including linting, formatting, testing, and deployments. Automating deployments with scripts and Git hooks can help avoid mistakes. Popular CI-CD frameworks like Jenkins offer powerful orchestration but can be challenging to work with. GitHub Actions are flexible and approachable, allowing for environment setup, testing, deployment, and custom actions. A custom AppleTools Eyes GitHub action simplifies visual testing. Other examples include automating content reminders for sharing old content and tutorials.
DevOps is a journey that varies for each company, and remote work makes transformation challenging. Pull requests can be frustrating and slow, but success stories like Mateo Colia's company show the benefits of deploying every day. Challenges with tools and vulnerabilities require careful consideration and prioritization. Investing in documentation and people is important for efficient workflows and team growth. Trust is more important than excessive control when deploying to production.
Slow CI has a negative impact on productivity and finances. Debugging CI workflows and tool slowness is even worse. Dependencies impact CI and waiting for NPM or YARN is frustrating. The ideal CI job involves native programs for static jobs and lightweight environments for dynamic jobs. Improving formatter performance and linting is a priority. Performance optimization and fast tools are essential for CI and developers using slower hardware.
Tobias Koppers introduces TurboPack and TurboEngine, addressing the limitations of Webpack. He demonstrates live coding to showcase the optimization of cache validation and build efficiency. The talk covers adding logging and memorization, optimizing execution and tracking dependencies, implementing invalidation and watcher, and storing and deleting invalidators. It also discusses incremental compilation, integration with other monorepo tools, error display, and the possibility of a plugin system for Toolpag. Lastly, the comparison with Bunn's Builder is mentioned.
Let's talk about React and TypeScript, Yarn's philosophy and long-term relevance, stability and error handling in Yarn, Yarn's behavior and open source sustainability, investing in maintenance and future contributors, contributing to the JavaScript ecosystem, open-source contribution experience, maintaining naming consistency in large projects, version consistency and strictness in Yarn, and Yarn 4 experiments for performance improvement.
Desplegar aplicaciones React Native manualmente en una máquina local puede ser complejo. Las diferencias entre Android e iOS requieren que los desarrolladores utilicen herramientas y procesos específicos para cada plataforma, incluidos los requisitos de hardware para iOS. Los despliegues manuales también dificultan la gestión de las credenciales de firma, las configuraciones de entorno, el seguimiento de las versiones y la colaboración en equipo. Appflow es la plataforma de DevOps móvil en la nube creada por Ionic. Utilizar un servicio como Appflow para construir aplicaciones React Native no solo proporciona acceso a potentes recursos informáticos, sino que también simplifica el proceso de despliegue al proporcionar un entorno centralizado para gestionar y distribuir tu aplicación en múltiples plataformas. Esto puede ahorrar tiempo y recursos, permitir la colaboración, así como mejorar la confiabilidad y escalabilidad general de una aplicación. En este masterclass, desplegarás una aplicación React Native para su entrega en dispositivos de prueba Android e iOS utilizando Appflow. También aprenderás los pasos para publicar en Google Play y Apple App Stores. No se requiere experiencia previa en el despliegue de aplicaciones nativas, y obtendrás una comprensión más profunda del proceso de despliegue móvil y las mejores prácticas para utilizar una plataforma de DevOps móvil en la nube para enviar rápidamente a gran escala.
Walt te mostrará 2 formas de crear rápidamente un sitio web en Vultr: desde cero utilizando archivos HTML y CSS con Object Storage, y con el Marketplace de 1 clic de Vultr.
Desplegar y gestionar aplicaciones JavaScript en Kubernetes puede volverse complicado. Especialmente cuando una base de datos también debe formar parte del despliegue. MongoDB Atlas ha facilitado mucho la vida de los desarrolladores, sin embargo, ¿cómo se integra un producto SaaS con su clúster de Kubernetes existente? Aquí es donde entra en juego el Operador de MongoDB Atlas. En este masterclass, los asistentes aprenderán cómo crear una aplicación MERN (MongoDB, Express, React, Node.js) localmente y cómo desplegar todo en un clúster de Kubernetes con el Operador de Atlas.
Las Azure Static Web Apps se lanzaron a principios de 2021 y, de forma predeterminada, pueden integrar su repositorio existente y implementar su aplicación web estática desde Azure DevOps. Este masterclass demuestra cómo publicar una Azure Static Web App con Azure DevOps.
Cómo desarrollar, construir e implementar microservicios Node.js con Pulumi y Azure DevOps
Workshop
2 authors
El masterclass ofrece una perspectiva práctica de los principios clave necesarios para desarrollar, construir y mantener un conjunto de microservicios en el stack Node.js. Cubre los detalles específicos de la creación de servicios TypeScript aislados utilizando el enfoque de monorepo con lerna y yarn workspaces. El masterclass incluye una descripción general y un ejercicio en vivo para crear un entorno en la nube con el framework Pulumi y los servicios de Azure. Las sesiones están dirigidas a los mejores desarrolladores que deseen aprender y practicar técnicas de construcción e implementación utilizando el stack Azure y Pulumi para Node.js.
Comments