NPM, y el por qué no es la solución que necesitamos

No creí que llegaría a escribir sobre este tema tan pronto, pero es necesario debido a que me interesa cerrar esta reciente Trilogía de la Programación Web, y nada mejor que hablar sobre NPM. Empezamos hablando de la inevitable muerte de Flash, y de cómo fue una tecnología que vimos adecuada en su momento y pasó a ser inaceptable en la actualidad. Continuamos con jQuery, la librería monstruo de JavaScript, que aún hoy es la más utilizada pero que se ha puesto en jaque a futuro. Y hoy le toca a NPM, el gestor de paquetes de Node que se presentó como una especie de salvación para el mantenimiento de Librerías, y sin embargo no lo vemos actualmente como algo muy presente en el futuro cercano (salvo que cambie ciertas cosas).

¿De dónde salió NPM?

Es una gran cuestión. NPM es un sistema para gestionar paquetes, concretamente uno para NodeJS, el más popular en la actualidad. Se instala en cualquier sistema operativo al instalar el paquete global de Node, y por línea de comando permite instalar paquetes en un proyecto del mencionado sistema NodeJS. NPM tiene una historia corta pero intensa en la informática, ya que se trata de una necesidad básica. A medida de que las librerías de JavaScript se complejizaban, se volvía necesario un método para poder instalar dependencias de una forma automática. Antes de esto, la forma más "cómoda" de instalar dependencias era la tradicional de las TAG script y a lo sumo usar un CDN. Con NPM eso mejora ampliamente, ya que al utilizar el CLI para instalar una librería, esta va a pedir las dependencias y las va a instalar. Esto además permite elegir que versión instalar, haciendo que la persona encargada del desarrollo eliga que versión "forzar" en caso de no querer utilizar la versión más reciente. Todas necesidades básicas, de las cuales gozamos tan solo hace poco más de 5 años en JavaScript.

¿Cuál es el Problema?

Pese a sus virtudes, NPM cobija en sus alas una serie de problemas de gran consideración. Aclaro, no se tratan de detalles de funcionamiento, sino de problemáticas muy serias que siguen sin solucionarse. Curiosamente, su virtud es también su mayor debilidad: las dependencias.

¿Cuando un paquete debe tener como dependencia otro paquete? Francamente no hay una respuesta adecuada para eso, lo que lleva a confusión y a utilizar un sin fin de dependencias para conseguir un paquete "cómodo". El problema surge cuando empezamos a sumar grandes cantidades de bytes a fin de desarrollar una librería cerrada. En la mayoría de los casos, se toma como dependencia un paquete solo por una o dos funciones, ya que NPM tiende a facilitar esto. Antaño, como debíamos leer el código de la librería que queríamos como dependencia, muchas veces no era rentable utilizar dicha librería como parte de otra librería y se optaba por extraer solo lo necesario, haciendo que las librerías se optimizaran en tamaño.

Esto está produciendo una carga masiva de paquetes con un peso excesivo que no se justifica para nada. Y claro que se han realizado soluciones muy buenas, como que NPM limpia paquetes que ya no se utilizan, o herramientas como Angular y su motor Ivy que al compilar se queda solo con lo que necesita (esto también ocurre en Node). Pero para el desarrollo se ha hecho más bien poco, la carpeta de node_modules puede tranquilamente pesar alrededor de 1 Gb si no se tiene cuidado, incluso un proyecto vacío de Angular ronda los 300 Mb (sin contar los assets del proyecto, que son los que deberían elevar realmente el peso). Y aunque en algunos casos se pueda justificar, en la mayoría es un sin sentido. A esto debemos sumarle que cada vez que necesitemos crear un nuevo proyecto de Node que comparta paquetes, deberemos importarlo de nuevo, teniendo varias veces los mismos paquetes en nuestro ordenador de trabajo. Entiendo el punto y lo importante del control de versiones, nadie pide algo global como Python, pero el trabajo con entornos en Node no es para nada simple, y es una necesidad. Si en el pasado el atractivo de las librerías JavaScript era que "pesaban menos de 1 Kb", los paquetes de Node optimizados alardean de "solo tener 3 dependencias".

Otra problemática derivada de la gestión de NPM, aunque no tengan la culpa en realidad, es como los usuarios utilizan el sistema. Si buscan en el sitio de NPM algo así como "angular bootstrap" se van a encontrar con cientos de paquetes de NPM que lo hacen, la mayoría son forks actualizados de un paquete de hace unos años llamado "ng2-bootstrap" que luego pasó a ser "ngx-bootstrap". ¿El resultado? Páginas y páginas de paquetes que hacen lo mismo, no hay forma de saber cual necesitamos realmente, o cual se va a mantener en el futuro.  En este sentido el gestor Yarn es un poco más manejable, pero también es cierto que al ser menos popular el control de paquetes se hace más llevadero.

Conclusiones

Está claro que NPM llegó para quedarse, y eso no tiene nada de malo, no hay manera de programar de forma correcta en Web sin algo como NPM (por más que muchos docentes quieran hacer creer que si). Y esto es como todo, una vez que uno prueba la comodidad no quiere volver hacia atrás. Pero indudablemente NPM tendrá que sujetarse a ciertos cambios si quiere mantenerse como el principal gestor de paquetes (hoy lo salva su extensa popularidad, pero en su momento Flash también lo era).

NPM debería promover la creación de paquetes completos, donde el uso de dependencias sea algo más parecido a como funcionan los repositorios en Debian y con herramientas más cómodas para la generación y gestión de entornos (algo que a pesar de no ser fundamental, a medida que crecen los proyectos termina siendo una necesidad). Si no consigue esa organización poco a poco se enfrentará a otros inconvenientes (como la masiva cantidad de paquetes repetidos que hay), hasta ponerse en jaque frente a los futuros gestores (que visto lo visto terminarán apareciendo). Por supuesto no deja de ser mi opinión, y tampoco pretendo con esto predecir ningún futuro. Está claro que la programación con NPM es mejor que sin NPM, la pregunta acá es la siguiente: ¿es la única opción posible?