El Estado del Núcleo de Node.js

Hola a todos, gracias por venir a mi charla. Hoy voy a hablar sobre el estado del núcleo de Node.js. Para empezar, quiero mostrar algunas métricas de descarga. Estas métricas son de los últimos dos años aproximadamente y se puede ver que el número de descargas desde nodejs.org sigue aumentando, con la excepción de dos grandes caídas de tráfico relacionadas con las vacaciones de Navidad y cosas así, pero sí, Node sigue en aumento. A continuación, quiero hablar sobre el ecosistema, así que esta es una gráfica de modulecounts.com que compara el tamaño del ecosistema de npm con otros registros de paquetes populares para cosas como Rust, Java y Ruby, entre otros. Esto no representa necesariamente el núcleo de Node, sino el ecosistema más grande. npm es el único gestor de paquetes en esta gráfica que tiene más de 2 millones de paquetes. JavaScript es, con mucho, el ecosistema más grande del mundo, y esto viene con algunas advertencias, ya que npm también aloja cosas que no son solo módulos de Node.js, así que hay otras cosas allí. No todos los módulos son de gran calidad, pero hay algunos paquetes realmente buenos. También hay otros que probablemente no se usan mucho o no deberían usarse mucho, pero en general, creo que esto representa bastante bien la salud del ecosistema.

A continuación, quiero hablar sobre el programa de soporte a largo plazo de Node, también conocido como LTS. En 2015, Node creó un plan de LTS para equilibrar a los individuos y desarrolladores que desean incluir la mayor cantidad de características posible con los usuarios empresariales, que valoran la estabilidad a lo largo de los años, no solo días o semanas. Creamos este plan donde dos veces al año, en abril y octubre, lanzamos una nueva versión principal del proyecto. Puedes ver aquí en la gráfica en la parte superior, la barra inestable etiquetada como Main. Ahí es donde se realiza todo el desarrollo activo del proyecto. Parches, nuevas características, cambios rompedores, todo se incluye en la rama principal. Luego mantenemos varias ramas de lanzamiento a las que seleccionamos confirmaciones cada vez que hacemos un lanzamiento. Ahora mismo tenemos las versiones 14, 16, 18, 19 y 20 de Node como ramas de lanzamiento activas o próximas. Este año en abril, lanzaremos la versión 20, y luego en octubre lanzaremos la versión 21. Así que hacemos lanzamientos con números impares en octubre y lanzamientos con números pares en abril. La última versión principal se convierte en lo que llamamos la línea de lanzamiento actual durante seis meses. Ahora mismo, la versión 19 de Node es la versión actual, y después de ese período de seis meses, si es una versión con número impar, pasará a un período de mantenimiento abreviado donde recibirá cosas como correcciones de seguridad, pero es más bien un período de gracia para que las personas migren, mientras que las versiones con números pares pasan a lo que llamamos LTS activo durante un año, y en LTS activo, aún obtienes todo, excepto los cambios rompedores que se incluyen en la línea de lanzamiento actual, pero los mantenemos en la línea de lanzamiento actual durante unas semanas para asegurarnos de que sean estables y no haya grandes regresiones, y luego los retrocedemos. Obtienes los mismos cambios, pero a un ritmo más lento y con una mayor garantía de estabilidad. Después de esos 12 meses, las versiones con números pares pasan al modo de mantenimiento durante 18 meses, esto es para dar tiempo suficiente a las grandes empresas y demás para migrar a la próxima línea de lanzamiento que van a utilizar. Así que esta es una descripción general de todas las líneas de lanzamiento en este momento.

A continuación, quiero profundizar en cada línea de lanzamiento individualmente y ver qué está sucediendo allí. Node 14 está actualmente en modo de mantenimiento. Se le asigna el nombre en código Firmium, así que todas las versiones LTS se les asigna un elemento de la tabla periódica, en este caso Firmium. Creo que comenzamos con Argon y Node 4, Boron y Node 6, y así sucesivamente. Algunas letras no tienen elementos de la tabla periódica, en ese caso simplemente inventamos algunos.

Eso es solo un dato curioso. Volviendo a Node 14, llegará al final de su vida útil a finales de abril, por lo que probablemente puedes esperar 1 o tal vez 2 lanzamientos más entre ahora y entonces, pero si estás utilizando Node 14, realmente necesitas comenzar a migrar ahora.

Recomiendo apuntar a Node 18 si es posible, y la razón de eso es que Node 16 también llegará al final de su vida útil este año. Node 16 es conocido con el nombre en código gallium. Debería haber llegado al final de su vida útil en abril de 2024, pero solo será compatible hasta septiembre de 2023. Hay una diferencia de 7 meses, pero hay una buena razón para ello. La versión de OpenSSL que se incluye con Node 16 también llegará al final de su vida útil, por lo que como proyecto, tuvimos que equilibrar si queríamos seguir admitiendo Node 16 solo porque sí, o dejarlo desaparecer en lugar de pedir a las personas que ejecuten lo que podría ser una versión posiblemente insegura de OpenSSL cuando llegue al final de su vida útil.

He vinculado la publicación oficial del blog en la parte inferior de la diapositiva aquí, si deseas más detalles. Pero en general, solo recomendaría que si estás migrando desde Node 14, no vayas a la versión 16. Si actualmente estás en la versión 16, comienza a apuntar a Node 18.

A continuación, quiero hablar brevemente sobre Node 18. Node 18 se conoce con el nombre en código Hydrogen. Actualmente es una LTS activa y pasará a mantenimiento en octubre de este año. Una vez que esté en mantenimiento, se admitirá con parches de seguridad y cosas así hasta abril de 2025. Node 18 es muy estable en este momento y en realidad tiene muchas características que no están en Node 14 y 16. Personalmente, esto es lo que recomendaría utilizar en producción. Esto es lo que estoy usando en producción en el trabajo. Como dije, es muy estable y definitivamente es lo que debes apuntar ahora.

Siempre habrá personas que quieran utilizar las últimas y mejores cosas en producción. En este momento, eso sería Node 19. Node 19 no tiene un nombre en código de elemento de la tabla periódica porque nunca será LTS. Fue lanzado originalmente en octubre de 2022. Seguirá siendo la línea de lanzamiento actual hasta abril de 2023. En ese momento, tendrá algunos meses de soporte de mantenimiento y llegará al final de su vida útil en junio de 2023. Como mencioné, no entrará en LTS activa. No recomiendo usarlo en producción. En el pasado, tuvimos muchos casos en los que la línea de lanzamiento actual tenía regresiones que no se incluían en LTS. Eso ya no es tanto el caso. Las versiones con números impares parecen ser cada vez más estables, lo cual es bueno. Pero aún así no lo recomendaría para producción.

Hay un cambio notable en esta línea de lanzamiento. Se eliminaron las sondas de diagnóstico dTRACE, SystemTap y ETW. La razón de esto es simplemente que Node es un proyecto de código abierto dirigido principalmente por voluntarios. Nadie se ofreció como voluntario o se hizo cargo de mantener esos fragmentos de código. Se estaban convirtiendo en una carga de mantenimiento y se eliminaron. Hay un problema abierto invitando a cualquier persona que se sienta fuertemente acerca de estas cosas a que venga y las apoye nuevamente, pero por ahora, no están en la base de código.

Similar al gráfico que mostré al principio, este es un desglose de las descargas por diferentes líneas de lanzamiento de Node en los últimos dos años. La barra azul, que comienza en el extremo izquierdo y luego disminuye a medida que pasa el tiempo, es Node 14. Ese es el comportamiento esperado y lo que queremos ver. Las descargas aumentaron y luego pasó a modo de mantenimiento y comenzaron a disminuir. De manera similar, Node 16, que es la barra naranja, todavía está en proceso de aumentar y avanzar hacia la derecha. Espero que las personas, y parece que la tendencia ya está comenzando en este gráfico, comiencen a migrar de la versión 16 a Node 18. Node 15 y 17 no se muestran en este gráfico porque ya habían alcanzado el final de su vida útil cuando se compiló este gráfico. Luego, puedes ver la línea amarilla de Node 18 comenzando a ganar impulso un poco más de la mitad del gráfico y está aumentando lentamente. Como dije, si volvemos a hacer este gráfico en unos meses, imagino que Node 18 será considerablemente más alto, con suerte más que Node 16. Y luego, la pequeña parte verde en el extremo derecho es Node 19. Puedes ver que llegó al mundo más tarde que todas las demás líneas de lanzamiento. No ha tenido tanto éxito y espero que también veamos que comienza a desaparecer.

Entonces, si quieres elegir qué versión ejecutar en producción, ya he insinuado esto, pero definitivamente deberías ejecutar una versión LTS en producción, especialmente si Node es crítico para la misión, si estás ganando dinero con Node.js en producción, entonces quieres ser lo más estable posible. También debes preguntarte si puedes actualizar fácil y frecuentemente. Estar en la vanguardia implica que puede haber problemas. Si insistes en ejecutar Node 19 en producción, asegúrate de poder actualizar fácilmente porque las cosas se mueven mucho más rápido allí. Y luego, realmente debes preguntarte si realmente necesitas todas las características más nuevas. Algunas personas realmente las necesitan, pero muchas veces la respuesta es no. No necesitas estrictamente las cosas más nuevas y puedes esperar unos meses. Estas son solo recomendaciones. Puedes hacer lo que quieras, pero así es como recomendaría proceder.

A continuación, quiero hablar sobre algunas de las nuevas características que han llegado a Node a través del proyecto V8. La forma en que funcionan las cosas es que cuando hay una nueva característica de JavaScript, TC39 crea una especificación para ella. Los implementadores de navegadores o motores de JavaScript como V8 realmente desarrollarán las nuevas características y una vez que Node.js se actualice a una versión de V8 que incluya esas características, las recibiremos automáticamente.

Una de las cosas que tuvimos que agregar en Node es habilitar los reinos sombreados. Los reinos sombreados son la solución oficial del lenguaje para cosas como el módulo VM de Node, para poder ejecutar código en su propio reino, enviar entradas y obtener salidas. Es similar a VM, pero un poco más seguro que Eval, pero como aún está detrás de una bandera experimental en V8, tuvimos que agregar una bandera experimental en Node para desbloquear esas características.

También tenemos un par de nuevos métodos en las matrices. find last y find last index son similares a find y find index, pero comienzan desde el final de la matriz en lugar del principio. Se han realizado varias adiciones y mejoras en la API. Si estás utilizando las API de internacionalización, se ha mejorado la localización y se han agregado el formato de número y los valores admitidos en el método. También ha habido algunas mejoras de rendimiento relacionadas con los campos y métodos de clase. Por lo general, cuando se agregan nuevas características a V8, no están completamente optimizadas. Entonces, los campos y métodos de clase llegaron a V8, tuvimos acceso a ellos en Node, pero evitamos usarlos porque eran más lentos que las alternativas que utilizaban símbolos y otras cosas. Pero el rendimiento ha mejorado y ahora podemos recomendar completamente su uso en tu código.

Y luego, algo importante que ha llegado recientemente es la integración de promesas de JavaScript. Esto se dirige específicamente a las personas que utilizan WebAssembly. La forma en que generalmente funcionaba era que llamabas desde tu código JavaScript a WebAssembly y WebAssembly realizaba alguna operación sincrónica. Si necesitaba alguna funcionalidad personalizada, podías llamar de vuelta a JavaScript. Pero no había una forma real de tener una integración asíncrona entre JavaScript y WebAssembly. Con tantas de las nuevas API de JavaScript basadas en promesas o simplemente asíncronas en general, había una especie de desconexión. Esto es realmente una gran mejora en la calidad de vida para las personas que utilizan WebAssembly y Node.

A continuación, quiero destacar algunas de las API que hemos obtenido basadas en la compatibilidad con la plataforma web. Node intenta admitir, cuando tiene sentido, muchas de las mismas API que se pueden obtener en un navegador. Una de las más importantes que las personas han estado esperando durante años es Fetch. El proyecto finalmente logró hacer que Fetch sucediera. Junto con Fetch, también se agregaron muchas otras API como Request, Response y FormData. Tenemos Web Streams, que son la respuesta del navegador a las transmisiones de Node.js. Actualmente, no están altamente optimizados en Node, pero están mejorando poco a poco. Tenemos Web Crypto, Structured Clone, que es muy útil para poder copiar objetos. No voy a enumerar todas las cosas diferentes aquí, pero constantemente estamos tratando de mejorar nuestra compatibilidad con la plataforma web.

Otra característica importante que se implementó en Node 18 es un ejecutor de pruebas incorporado. Hay algunas formas de usar el ejecutor de pruebas. Existe el módulo de pruebas node:test dentro de Core que puedes requerir.

También hay un ejecutor de línea de comandos (CLI), que se habilita con guión, guión, prueba. Y si estás utilizando una versión anterior de Node que, ya sabes, no se ha adaptado a esto, como por ejemplo, actualmente Node 14 no tiene soporte para ello.

Algunas personas amables tomaron el código de Core, lo pusieron en un paquete en npm, y puedes instalarlo desde allí y obtener casi todas las mismas funcionalidades. Por lo tanto, admite muchas de las cosas que esperarías que un ejecutor de pruebas, soporte de pruebas, admita de forma predeterminada.

Por lo tanto, tiene subpruebas. Puede saltar pruebas. Puedes especificar solo pruebas, por lo que solo quieres ejecutar un subconjunto de tu conjunto de pruebas. Ganchos del ciclo de vida, como antes, antes de cada uno, después y después de cada uno, y cosas así. Y también admite simulación de forma predeterminada.

Actualmente no admite la simulación de módulos completos. Debido a algunas limitaciones en los módulos ES. Pero puedes simular funciones, métodos y cosas así. Tiene cobertura de código incorporada de forma predeterminada, que puedes habilitar con la bandera --experimental-test-coverage del CLI. Y ahora también puedes generar tus propios reportes personalizados.

Por lo tanto, hay algunos que están integrados en Node. De forma predeterminada, será TAP, que significa Protocolo de Prueba de Cualquier Cosa, que es un formato para expresar resultados de pruebas, que se utiliza, entre otros ecosistemas, no solo en Node.js. Y eso se enviará a través de la salida estándar, pero puedes personalizarlo. Puedes usar SPEC, que es un formato más legible para humanos. TAP, el formato pequeño donde solo se muestran puntos con X. No sé cómo se llama eso. Y luego puedes usar la bandera de destino del reporte de prueba, donde puedes decir dónde quieres que se envíen tus resultados. Por defecto, es la salida estándar, pero puedes usar la salida de error estándar y otras cosas.

Esto es solo una imagen rápida de cómo se ve una prueba. Admitimos pruebas sincrónicas, pruebas asincrónicas, devoluciones de llamada, etc. A la izquierda, aquí está lo que obtendrías si ejecutases la prueba anterior y generases la salida TAP. A la derecha está lo que obtienes con el reporte SPEC. Si quieres colores y cosas que sean un poco más amigables para los humanos, puedes usar eso.

Del TestRunner también surgió otra nueva característica llamada módulos principales solo con prefijo 'node-'. La diferencia aquí, si miras en la parte superior, estamos importando node:test y node:assert. Cada módulo principal se puede importar usando el prefijo 'node:', y eso es bueno porque permite que las herramientas y las personas que leen el código lo sepan.

No voy a mencionar todos ellos, nuevamente por falta de tiempo, pero vale la pena señalar que teníamos pruebas de snapshot, el assert.snapshot, pero la gente no estaba realmente satisfecha con la implementación, así que lo hemos eliminado y esperamos revisarlo para refinarlo un poco más.

Algunas características potenciales próximas, recientemente se abrió una solicitud de extranjero interfaz de función o FFI para el core. Actualmente, las personas están trabajando en soluciones para una mejor integración con TypeScript, agregando soporte de proxy a fetch y con suerte prometiendo más mejoras en los módulos core, solo quedan unos pocos en este momento. Nuevamente, todas estas son cosas futuras que pueden o no suceder, así que creo que probablemente sucederán, pero no quiero hacer promesas que no pueda cumplir. Y por último, quería mencionar algunos de los enlaces importantes relacionados con el proyecto, por lo que si tienes un informe de error o una solicitud de función, ve a nodejs slash node en GitHub. Si tienes una pregunta de soporte, puedes crear una discusión o ir a nodejs slash help. Si estás interesado en el calendario de lanzamientos, algunas de las cosas que mencioné anteriormente en esta charla, nodejs slash release tiene todos los detalles. Si tienes una vulnerabilidad de seguridad que encontraste, por favor repórtala en HackerOne con el enlace aquí, no la informes en el rastreador de problemas público. Y finalmente, nodejs está activo en la comunidad de OpenJS Foundation en Slack, por lo que hay un enlace aquí donde puedes unirte a Slack. Nodejs y nodejs slash core son los canales principales donde se discute el proyecto. Y eso es todo de mi parte. Solo quería hacer una mención a la empresa para la que estoy trabajando actualmente, Platformatic, que ayuda a simplificar la creación de API con Node.js mucho más fácil para las API REST, GraphQL, Metrix, todas las cosas que son un poco indiferenciadas, estamos tratando de hacerlas más simples para todos. Y eso es todo lo que tengo. Gracias nuevamente por venir a mi charla.