Cómo mantener las dependencias npm de tu proyecto

Es muy común encontrar proyectos que funcionan correctamente en producción, pero que ya no reciben mantenimiento activo: están en producción, funcionan y el cliente considera que el proyecto está terminado.

Por desgracia, esto no es del todo cierto. Solemos olvidar que, cuando un proyecto está terminado y en producción, eso no significa que no necesite mantenimiento. La mayoría de los proyectos aún deben revisarse y hay que resolver los incidentes cuando ocurren. Si lo comparáramos con comprar un vehículo, sería algo así: vamos al concesionario, elegimos el modelo adecuado, pagamos y lo disfrutamos mientras nos sea útil, sin hacerle ningún mantenimiento periódico, ¿verdad? Claro que no, y lo mismo ocurre con el software.

Al desarrollar proyectos de API REST o aplicaciones CLI con Node.js, es muy común usar npm, el administrador de paquetes de dependencias de código abierto, para incluir frameworks y herramientas en estos proyectos.

Hasta cierto punto, esto es beneficioso, ya que puede ayudarnos a reducir el tiempo de desarrollo. Incluir paquetes estables, bien probados y mantenidos por la comunidad permite satisfacer ciertas necesidades de nuestro proyecto. Sin embargo, también puede volverse en nuestra contra y convertirse en un problema.

A continuación, analizamos una situación común en un proyecto de Node.js. Algunos de estos problemas surgen cuando dejamos un proyecto sin supervisión y sin mantenimiento evolutivo ni preventivo.

Caso específico

Imagina un proyecto de API REST con Node.js que lleva 2 años o más en producción. Durante esos dos años, nadie ha hecho nada para actualizar o adaptar las dependencias a las nuevas versiones. Para desarrollarlo, se usó el paquete express como framework base para la funcionalidad CRUD. Además, se usó la biblioteca jsonwebtoken para generar tokens de seguridad y el paquete moment para la internacionalización de fechas.

Posibles problemas

El uso de bibliotecas de dependencias bastante nuevas puede considerarse el primer problema, ya que basamos parte de nuestra solución en software que la comunidad no ha probado y que, posiblemente, no evoluciona de forma constante.

En segundo lugar, basamos parte de nuestra solución en bibliotecas de «un solo contribuidor», como las llamo. Estas dependencias las desarrolla una sola persona, que se encarga de publicar mejoras, dar mantenimiento y resolver incidentes y, finalmente, decidir unilateralmente el rumbo que debe seguir ese software. Estas dependencias nos limitan considerablemente.

Como tercer problema, tenemos las dependencias que contienen otras dependencias. Sin embargo, esto no se ve a primera vista; es lo que comúnmente llamamos «Node Module Hole».

Fuente: https://github.com/JoseJPR/tutorial-nodejs-snyk-vuln-cost/blob/master/assets/video.gif

Encuentra más consejos al respecto aquí.

Algunas soluciones

1. ¿Realmente necesito esta dependencia?

En un proyecto de Node.js, el primer lugar donde debemos buscar información es en su propia documentación. La documentación de la API de Node.js contiene una gran cantidad de ejemplos prácticos de lo que podemos lograr por nuestra cuenta trabajando de forma «nativa» con la API de Node.js, sin dependencias externas.

2. Uso de microdependencias

Una vez que tenemos claro que necesitamos un componente para cubrir las necesidades de nuestro proyecto, debemos encontrar el adecuado. Al principio, solemos pensar que la primera opción que aparece en los resultados de búsqueda de Google (o en el buscador de npm) será la más apropiada, pero en muchos casos no es así. Debemos detenernos, pensar y analizar qué parte de lo que hace esta biblioteca necesitamos realmente. Tal vez haga mucho más de lo que necesitamos y termine incorporando a nuestro proyecto una biblioteca que en gran medida no usaremos.

3. Análisis del mercado

Debemos investigar un poco y buscar alternativas: el ecosistema de npm es muy amplio y podemos encontrar distintas bibliotecas que prácticamente hacen lo mismo. Pero ¿cuál elegir? En este caso, podemos usar herramientas web como Bundlephobia, que nos muestra una comparación del tamaño de cada paquete, o npmtrends, que muestra una comparación con información sobre el volumen de descargas o las contribuciones de la comunidad, entre otros parámetros.

Estas herramientas pueden ayudar a elegir la dependencia adecuada. Datos como el tamaño de la dependencia, el tamaño de la comunidad que la mantiene, la cantidad de versiones que ha tenido en los últimos meses o el número de descargas pueden ser indicadores importantes.

4. Uso de herramientas preventivas

Snyk lanzó la extensión de código abierto Vuln Cost para Visual Studio Code, que permite ver de forma muy fácil y rápida cuántas vulnerabilidades tiene nuestro software a partir del archivo package.json e incluso de cada archivo que contiene una importación de biblioteca.

Actualmente, en un proyecto de Node.js podemos incorporar dependencias mediante require y import, ya sea por completo o de forma parcial, si se permite. En la siguiente imagen puedes ver un ejemplo claro de cómo se ve esto con el proyecto descrito anteriormente (express + jsonwebtoken + moment):

Fuente: https://github.com/JoseJPR/tutorial-nodejs-snyk-vuln-cost/blob/master/assets/video.gif

Si buscas más recursos sobre cómo usar Vuln Cost, consulta los tres videos a continuación:

• Cómo instalar la extensión Vuln Cost en Visual Studio Code

• El «require» de bibliotecas de JavaScript y cómo verificar vulnerabilidades

• La importación de bibliotecas de JavaScript y cómo verificar vulnerabilidades

Conclusiones

Uno de los desafíos que la industria del software siempre ha enfrentado es explicar y hacerle entender al usuario final que el software tiene una necesidad básica: recibir mantenimiento y evolucionar. Esto permite, por ejemplo, adaptarlo a las actualizaciones del sistema operativo, mejorar su rendimiento o eliminar posibles puntos vulnerables.

Otro desafío es lograr que los equipos de desarrollo tengan tiempo para reflexionar, actualizarse y capacitarse con el fin de encontrar las alternativas más adecuadas al desarrollar software; la primera opción que se nos presenta no siempre es la correcta.

Las cuatro soluciones que analizamos anteriormente pueden ayudarte a desarrollar una base de código fácil de mantener, de alta calidad, escalable y más segura.