Node Just Run

Muy bien. Así que esta charla trata sobre el uso de Node para facilitar cosas muy comunes que los ingenieros hacen hoy en día en su entorno local y también en CI. Muchas de esas cosas que hoy en día requieren bastante configuración y cosas así, no queremos eso. Solo queremos que funcione. Así que, sí, idealmente, solo dices Node y le das lo que quieres ejecutar, y simplemente lo hace. Nos estamos acercando a eso, como hemos visto con TypeScripting y cosas así. A medida que más cosas se integran para las cosas que aún no están integradas en Node, tenemos ganchos de personalización.

Antes de profundizar demasiado en eso, un poco sobre mí. Soy Jacob Smith. Puede que me hayas visto en GitHub o por ahí como JacobJingleheimer. Soy delegado de TC39, delegado de invierno de TC55. He sido mantenedor principal, colaborador principal de Node.js durante entre medio y una década ahora. Organizo el code bar de Ámsterdam, y en mi trabajo diario, soy ingeniero de software principal. Así que el objetivo aquí es que solo quiero ejecutar mis cosas.

Por ejemplo, Node main TSX. Si esto fuera solo un archivo TS, Node podría hacerlo por sí mismo. Pero como tiene un montón de otros tipos de archivos en él, si intentaras hacer esto ahora mismo, Node obviamente fallaría. Este es un archivo bastante simple, así que es como, solo hazlo. No hay nada realmente loco sucediendo aquí, y todas estas cosas que queríamos hacer son bastante estándar. Así que el problema es que Node solo entiende cuatro tipos de cosas. C++ a través de plugins y a través del Node N API, JSON, Javascript, que es en el sabor de CommonJS o ESM, o Wasm.

Node necesita entender tres otros tipos de cosas para hacer que main.tsx funcione. Así que JSX o TSX, un módulo CSS, y una URL de medios. Así que lo que muchos de ustedes podrían buscar es un bundler. Los bundlers son para producción. Realmente no quieres usar eso en tu entorno local solo para ejecutar tus cosas o para ejecutar pruebas, CI, ese tipo de cosas. Puedes, pero esa no es realmente la solución.

Así que podemos extender Node a través de los ganchos de personalización que han existido en Node durante bastante tiempo. Ahora se están volviendo un poco más estables, y puedes ver cómo se ven en solo un segundo. Así que hay dos versiones de esto. Está el original async hooks, más comúnmente ahora hecho por module register, y tenemos sync hooks a través de register hooks. Se ven bastante similares, y el diablo está en los detalles.

Los async hooks facilitan hacer trabajo asincrónico de una manera que parece ser sincrónica. Cómo hacemos eso bajo el capó es súper loco. Lo llamo el upside down. Involucra un worker y atomics y cosas así. No necesitas preocuparte por eso. Nosotros sudamos ese dolor por ti. Pero si no necesitas nada particularmente especial, entonces podrías simplemente usar los ganchos sincrónicos disponibles. Esos son mucho más eficientes, porque entonces no tienes que ir y venir entre el upside down, que tiene un costo no trivial.

Además, iniciar la infraestructura que necesitamos para facilitar ese trabajo asincrónico también es bastante no trivial. Es genial cuando lo necesitas, pero si no lo necesitas, entonces no lo uses. ¿Por qué usar esto? Volvemos a algunos conceptos básicos de ingeniería aquí con el principio de responsabilidad única. Quieres aislar y encapsular la funcionalidad de estas cosas en sus piezas individuales. Si vas a manejar módulos CSS, solo quieres la cosa que maneja módulos CSS. Si vas a tener consultas de medios, solo tienes URLs de medios. Tienes la cosa que solo maneja URLs de medios.

Así que hace mucho tiempo, comencé con esto, y me encontré haciendo muchas de las mismas cosas. Así que reuní esta colección de loaders, llamada así en ese momento, ahora ganchos de personalización. Así que si necesitas módulos CSS, URLs de medios, ese tipo de cosas, tenemos un montón de ellos. Son súper pequeños. En la mayoría de los casos, no tienen dependencias. A veces tienen solo una. Y simplemente alimentas eso en Node, y de repente entiende cómo lidiar con esas cosas.

Cuando consumes estas cosas, hay algunas formas diferentes de hacerlo. Así que lo que estás viendo aquí es la forma asincrónica. Se ve casi exactamente igual que la sincrónica. Y bajo el capó, un loader con ganchos se verá algo así. Como puedes ver, esto es muy, muy pocas líneas de código para hacer que Node entienda cómo lidiar con este tipo de cosas. La implementación real de esto en Node.js loaders ahora es un poco más complicada, porque maneja tanto sincrónico como asincrónico. Así que hay algo de magia sucediendo allí. Pero este fue en realidad el original. Así que hay resolver y cargar.

No tienes que saber mucho sobre cómo funcionan estas cosas. Resolve encuentra algo, load lo carga. Trabajan juntos para que Node acepte lo que le estás dando y luego lo use. La versión sincrónica de esto es casi idéntica. Básicamente, solo dejas caer async y dejas caer un peso. Así que como viste antes, cuando estás registrando un gancho o un loader, solo llamas a register, register hooks. Esta es la versión sincrónica de esos. Y es casi exactamente lo mismo. En lugar de alimentarlo con la ruta para importar en sí mismo, harías esa importación desde el archivo y luego alimentarías esas exportaciones en la utilidad register hooks de Node.

Así que, por supuesto, a todos les encanta verlo. La prueba está en el pudín. Así que tengo una demostración rápida aquí para mostrarte cómo funciona esto realmente y por qué es útil. Creo que verás bastante rápido por qué esta pequeña cosa realmente puede tener un gran impacto. Así que este es un archivo bastante estándar que verás en el desarrollo web. A la izquierda, tienes un archivo TSX. Está importando algunos activos de medios, default PNG, un módulo CSS. Tiene algo de JSX allí con algunos tipos, ese tipo de cosas. Construyendo eso. Luego, en el lado derecho, tienes una prueba. Resulta que está aprovechando la biblioteca de pruebas. Va a ejecutar esas cosas. La prueba contiene JSX, y también tratará con esos módulos CSS y ese tipo de cosas.

Así que podrías optar por algo muy, muy contundente que básicamente hará una compilación completa y luego compilará todo tu material. Realmente no quieres hacer eso porque hará que tu material sea súper lento. Uso estos ganchos de personalización cuando ejecuto mi propio CI y proyectos y cosas. Así que cientos o miles de pruebas generalmente terminan en un par de segundos. Tal vez a veces incluso menos. Si intentaras hacer eso con un paquete completo de algo, o si lo estás haciendo en una prueba o algo así, tomaría mucho, mucho más tiempo. Pero puedes ver aquí, si hago Node Run test, están todos hechos. La demora inicial que viste allí es porque esto está usando ganchos asincrónicos.

Así que hay alrededor de un segundo que tarda Node en iniciar todo eso para facilitarlo. En realidad, no lo necesita. Así que puedes eliminar eso. Solo quería mostrarte una especie de peor caso. Sigue siendo bastante rápido. Y luego, cuando quieres ver la cosa en sí, esto es lo que realmente está haciendo. Así que es una aplicación bastante simple. Toma mi avatar de GitHub y lo coloca aquí.

Cuando estás ejecutando esto en CI, todo ese tipo de cosas, se comporta básicamente igual, solo que obviamente no está renderizando nada a una salida visual como esta. Lo primero que podrías pensar es, pero dijiste que no más configuración. Bueno. Técnicamente cierto. Tienes que tener un poco de configuración para decir, como, estoy usando CSS modules. Estoy usando este tipo de cosas. Pero la cantidad de configuración para ello es bastante trivial.

No tienes que decirle, como, empareja esto con esto. Solo dices, como, CSS modules, sí. Media URLs, sí. Así que es este tipo de caso clásico de los viejos tiempos de interminables plugins de WordPress, como que no funciona? ¿Agregar otro plugin de WordPress? Más o menos, pero no realmente. Ese era un problema completamente diferente. Estas son cosas bastante pequeñas, encapsuladas. Hacen una cosa. Deberían hacer una cosa. Y generalmente no interactúan demasiado entre sí.

Así que hay alternativas en el mercado. Vite y Vitest son bastante populares. Funcionan de una manera un poco similar. Creo que probablemente no obtendrás el mismo rendimiento de ellos que obtendrás de lo que acabo de mostrarte. Porque lo que acabo de mostrarte es básicamente solo Node en sí. Así que cualquier cosa más que eso es más que Node en sí. Y eso va a costar.

Así que dices, está bien, pero estos son como seis de uno, media docena del otro. No realmente. El diablo está en los detalles aquí. Los customization hooks te permiten usar exactamente la cantidad que necesitas. Mientras que muchas de las otras soluciones tendrán un enfoque más de cocina completa para ello. Cubrirán un espectro mucho más amplio de cosas básicas. Y luego cuando necesitas más que eso, optas por esas cosas.

Eso te dará un costo que probablemente no quieras pagar. Algunas veces podría ser que si estás usando muchas cosas, entonces es un poco menos para que hagas. Depende de tu necesidad. Así que como estaba diciendo, solo lo que necesitas. Algunos números aquí. El impacto en el tamaño es bastante significativo. Los loaders que te he mostrado, los customization hooks son de unos 20 kilobytes. Frente a 1.6 meg para V test. Los customization hooks son diminutos. Si estás tratando de ejecutarlo, dependiendo de lo que estés haciendo, ambos son realmente rápidos.