Por qué es finalmente el momento de que los desarrolladores aborden el caos de Node.js y NPM

Node.js es una plataforma única y extraña. En particular, hay un ejemplo realmente bueno de "quien posiblemente pensó que esta era una buena idea" que es fácil de señalar, debido al estallido de caos que lo rodeaba.

En 2016, el servicio de mensajería Kik (piense en LINE, excepto en Canadá) solicitó al desarrollador Azer Koçulu, que tenía un paquete no relacionado con el mismo nombre, cambiar el nombre de su paquete en el administrador de paquetes de NPM. Después de declinar, los abogados que representan a Kik contactaron con el gerente general de NPM, Issac Schlueter, quien reasignó la propiedad del paquete a Kik. Koçulu no publicó todos sus módulos de NPM en protesta, entre ellos el paquete "left-pad", rompiendo todo en el despliegue que dependía del paquete.

El paquete fue utilizado por Node y Babel, entre otras cosas. Se había descargado 575,000 veces en la semana anterior al incidente. Las consecuencias fueron tan malas que NPM no había publicado el paquete para solucionar la situación. Con un nombre como "left-pad", ¿qué cosa más importante hace este paquete que requiera importar este paquete?

Es simplemente esto:

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;
}

Leftpad (Almohadillas Izquierda). Como su nombre indica. Sería preocupante si hiciera algo más.

Ahora, piensa en esta situación. El problema de denominación del paquete es una confluencia del uso enérgico de los abogados y una reacción rápida a un programador que tiene la manta sacada de debajo de él. Debe sacar sus propias conclusiones sobre la conveniencia de involucrar a los abogados en esta situación, y sobre la conveniencia de la reacción de Koçulu. También debe sacar sus propias conclusiones sobre el diseño de un administrador de paquetes que permita que un paquete ampliamente desplegado sea sin publicar de forma global sin demora, lo que rompe los sistemas de producción.

Ese no es el problema principal.

El problema es que hay tantas cosas que se pueden romper con un paquete. ¿Quién necesita este paquete? ¿Por qué crearías una dependencia por algo tan obvio?

Node.js está lleno de paquetes exactamente como este. JavaScript no tiene una biblioteca estándar, lo que deja a los programadores de Node.js la opción de escribir funciones básicas de manejo de cadenas cada vez que inician un nuevo proyecto, o importar paquetes individuales cada vez que se topan con algo que debe hacerse en orden para completar el objetivo real del programa.

NPM habilita este comportamiento al hacer que paquetes como el Leftpad sean triviales para importar. En otras circunstancias, muchos programadores probablemente copiarían algo de Stack Overflow o sitios web similares. La calidad de ese código y la aplicabilidad de ese código en el caso de uso previsto son probablemente sospechosos. NPM, por sus fallos, crea una cadena de propiedad para el código importado, no solo un mosaico de fragmentos que se encuentran en los tableros de mensajes.

El problema anterior de la publicación repentina de paquetes, que todavía es posible en NPM a pesar del incidente con Leftpad, hace que la posibilidad de tener incluso cantidades moderadas de paquetes importados sea poco atractiva. La falta de seguridad real en NPM hace que la frecuencia de importación de paquetes para cosas triviales sea un problema, como señaló David Gilbertson en este ensayo de enero sobre inserción de código y la vida "en una época donde las personas instalan paquetes npm como si estuvieran sacando analgésicos."

Entonces, con una combinación de este problema histórico con "micropaquetes" y razonable precaución sobre la seguridad, la mente de la colmena de um Internet descendido sobre un programador prolífico: Jon Schlinkert. Schlinkert está diseñando "un sistema de cadena de suministro enfocado en llevar el comercio a regiones empobrecidas". También tiene 821 repositorios en GitHub, y según todas las apariencias, está haciendo un uso completo de cada uno de ellos.

Schlinkert es responsable del paquete is-odd, que tiene poco más de 2,8 millones de instalaciones en la última semana. Ha escrito docenas de paquetes que se encuentran dentro de la amplia categoría de paquetes de verificación de tipos. El paquete is-odd está generando críticas debido a una cadena de dependencias que lo conectan a nanomatch y micromatch, el último de los cuales es una dependencia de más de 300 paquetes, incluidos el navegador sincronizado y el paquete web.

Por su parte, Schlinkert insiste en que "el ecosistema de NPM está fomentando la creatividad", pero que la proliferación de paquetes de verificación de tipos es un problema de JavaScript que, dada la falta de una biblioteca estándar, no es una conclusión equivocada. Para la proliferación propia de paquetes de Schlinkert, señaló que muchos de ellos están relacionados con una biblioteca generadora de proyectos que él está diseñando, y que los módulos tardan 15 minutos en publicarse. Él organiza los módulos de esta manera por el bien de las pruebas unitarias.

Esto es razonable. En última instancia, Schlinkert está trabajando dentro de un ecosistema con importantes problemas estructurales. Atacar personalmente a alguien por eso es injustificado. Dicho esto, NPM necesita abordar los problemas estructurales que permiten, si no promueven directamente la producción de, múltiples fuentes que se superponen en el administrador de paquetes.