Esta semana santa ha sido bastante movida en el complejo mundo de las dependencias entre paquetes NPM. Un programador decidió retirar una pequeña función de apenas unas lineas de código y como consecuencia muchos paquetes, algunos tan importantes como el propio NPM o Babel, dejaron de funcionar.
El paquete en cuestion es pad-left, que ofrece una funcion para añadir ceros por la izquiera al convertir un entero a cadena de caracteres. Esta pequeña función es en la práctica extremadamente popular y tiene millones de descargas cada mes, sobre todo por ser utilizada como dependencia interna en algunos de los paquetes más populares de NPM.
Parece ser que su creador, Azer Koçulu, fue víctima una desagradable actuación por parte de NPM sobre la publicación de un paquete denominado Kik y que molestó a kik.com, cuyo nombre coindice con el paquete publicado (también puedes leer el punto de vista de Kik de todo este embrollo).
Por todo ello, seguramente bastante enfadado por la actuación de NPM, Azer decidió dar de baja todos sus paquetes publicados en NPM y como consecuencia «el mundo tembló» ya que miles de descargas de paquetes muy populares dejaron de funcionar sin explicación aparecente.
Este es el pequeño código que, de repende, dejaba de estar disponible:
module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; if (!ch && ch !== 0) ch = ' '; len = len - str.length; while (++i < len) { str = ch + str; } return str; }
Para «resolver» en problema, Laurie Voss, CTO y cofundador de NPM, tomó la decisión sin precedentes de restaurar el paquete borrado. Cuando un paquete es eliminado no es posible volverlo a restaurar, pero en este caso se ha tomado una medida excepcional, tal y como explicó Laurie en un tweet.
Aunque el problema parece solventado, la verdad es que deja al descubierto la fragidad del sistema de dependencias encadenadas. La mayor parte de nosotros usamos los paquetes sin preocuparnos de que dependencias tienen y, aunque instalen decenas de paquetes prácticamente desconocidos, confiamos que todo funcionará correctamente, ahora y en el futuro.
Como hemos podido comprobar, el desagradable incidente con un programador de Oakland y una empresa Ontario, puede hacer templar los cimientos de miles de paquetes y volver locos a muchos desarrolladores que no entendíamos que estaba pasando al intentar instalar paquetes que hasta hace unos dias funcionaban sin problemas.
Es verdad que el código del paquete pad-left no es muy complejo, pero es habitual pensar que si algo está ya escrito y funciona bien, por qué no utilizarlo. Bueno, quizas debamos valorar más despacio que utilizamos, que origen tiene y que futuro le espera. Este ha sido un caso a gran escala y la propia NPM ha actuado, pero en otros casos más pequeños y menos conocidos podemos encontrarnos con un problema de dificil solución. Es posible que esto sólo haya sido una anecdota, pero da que pensar.
¿Qué opináis? ¿Cómo deberíamos actuar? ¿Debemos confiar o desconfiar de los paquetes y sus dependencias?
Novedades
HTTP2 para programadores. Enviar mensajes del servidor al cliente con Server Sent Event (sin WebSockets)
En esta charla, organizada por MadridJS, Pablo Almunia nos muestra cómo la mayoría de nosotros cuando oímos hablar por primera vez de HTTP2 nos ilusionamos con las posibilidades que presumiblemente se abrían para el desarrollo de soluciones web avanzadas y cómo muchos nos sentimos defraudados con lo que realmente se podía implementar.
En esta charla podemos ver cómo funciona el HTTP2, que debemos tener en cuenta en el servidor para hace uso de este protocolo y, sobre todo, cómo podemos enviar información desde el servidor al cliente de forma efectiva y fácil. Veremos con detenimiento cómo por medio de los Server-Sent Events (SSE) podemos recibir en el cliente datos enviados desde el servidor sin utilizar websocket, simplificando enormemente la construcción de aplicaciones con comunicación bidireccional.
Observables en Javascript con Proxies
En esta charla, organizada por MadridJS, Pablo Almunia nos habla de la observación reactiva de objetos en Javascript por medio de Proxy. Se describe paso a paso cómo funcionan los Proxies y en que casos pueden ser nuestro mejor aliado. Veremos que no hay que tenerles miedo, son bastante sencillos de utilizar, y nos ofrecen una gran abanico de posibilidades.
Aplicaciones JAMStack, SEO friendly y escalables con NextJS
En esta charla de Madrid JS, Rafael Ventura nos describe las funcionalidades clave de NextJS, nos muestra en vivo cómo desarrollar una completa aplicación JAMStack con Server Side Rendering (SSR) y Static Site Generation (SSG) y termina mostrando como publicar esta aplicación en Vercel.
Stencil JS: mejora el Time To Market de tu producto, por Rubén Aguilera
En esta charla Rubén Aguilera nos cuenta los problemas que tienen muchas empresas a la hora de sacar productos accesibles, vistosos y usables en el Time To Market que requiere Negocio y cómo podemos minimizar este tiempo gracias al DevUI con StencilJS para adecuar una aplicación de Angular a las exigencias del mercado en tiempo record.
Creo que por lo general somos bastante confiados y pensamos que cuando está en NPM el módulo ya no va a pasar nada pero olvidamos como comentas la dependencias cruzadas.
Cuando esta semana me enteré de esto por medio de un artículo titulado «How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript» empecé a pensar la fragilidad que puede tener el sistema de módulos para un caso como el que le ocurrió al autor.
El modelo de paquetes y dependencias ha buscado fórmulas para protegerse de los cambios de interfaz y funcionalidad entre versiones, pero está completamente al decubierto ante la retirada de un paquete. Que yo sepa, no hay mecanismos para protegerse de esta circunstancia y, como consecuencia, la caida en cascada de los paquetes es terrorífica.
La maravilla del software libre es que nos permite no solamente reutilizar sino incluso copiar dicho código.
¿Tiene dependencias? Es nuestro deber aislar lo que realmente nos interesa e instalarlo en nuestras propias máquinas para luego tener nuestros propios repositorios (a menos que se quiera colaborar directamente en esos módulos npm, es decir, contribuir subiendo nuestras propuestas PERO ESA ES LA MINORÍA DE LOS CASOS).