El futuro de npkill: Más allá de los node_modules

Npkill - road to v1.0 con cajas de colores.
Npkill - road to v1.0 con cajas de colores.
Otros idiomas: English

La llegada de npkill v1.0 está a la vuelta de la esquina, y con ella llegan nuevas decisiones que pueden marcar un antes y un después en el proyecto.

Esta actualización probablemente será una de las más importantes de todas, ya que el principal cambio será que el core se expondrá como una API pública que abrirá un montón de puertas. Entre ellas, una versión web de la herramienta.

Sin embargo, hay un cambio más ambicioso que me ronda por la cabeza y que pone sobre la mesa una serie de dilemas que puede elevar el proyecto un peldaño… o puede convertirse en una cagada recordada durante mucho tiempo.

El Origen y la necesidad

Npkill nació por una necesidad muy específica y personal. Buscar y borrar node_modules. Nada más. Una premisa tan simple y básica que si me hubieran dicho que iba a tener un impacto tan grande como lo tiene hoy día en el ecosistema me hubiera echado a reír.

El impacto de npkill en los diferentes ecosistemas de desarrollo

Con el tiempo fuimos viendo cómo el proyecto iba calando en otros ámbitos. Si bien npkill estaba claramente enfocado en el ecosistema de node, pronto empezaron a surgir otras alternativas basadas la misma idea pero en otros ámbitos. Killposer, Decomposer (php) o npkill-rs (rust) son tres ejemplos de utilidades muy bien portadas a sus ecosistemas. Por supuesto esto es algo genial y demuestra que hay un dolor común y frecuente sin importar la tecnología sobre la que se trabaje. Resulta que el meme de los node_modules no es solo exclusivo de estos.

La jaula dorada de su propia identidad

Ciertamente lo que hace brillar a npkill es su motor de búsqueda y su interactividad. Y siento que es una pena, que a pesar del esfuerzo de tantos colaboradores, su uso principal siga girando en torno a los node_modules.

El problema de la especialización

Sí, es cierto que desde hace tiempo existe la opción -t --target, que permite especificar cualquier otro directorio como objetivo. Pero siendo honestos, no es ni tan cómodo ni tan intuitivo. Más aún si no estás familiarizado con la herramienta por todas las opciones que ofrece y algunas de ellas no es que sean precisamente tan esenciales. Pero eh! ¡Puedes cambiar el color del cursor! (--color).

Perfiles para todos

Cajas de colores *md

Por ello se me ocurrió una idea: ¿Y si npkill pudiera ser útil para cualquier desarrollador out-of-the-box, sin importar a que se dedique?

Esta idea buscaría extender el ámbito nativo para dejar de ser solo la herramienta para los que trabajan con los node_modules, sino también la herramienta para cualquier desarrollador. ¿Cómo? Muy fácil. Añadiendo perfiles predefinidos.

Estos perfiles se podrían definir a la hora de lanzar el programa con --profiles o desde un sub-menu dentro de la TUI con opciones como python, java, rust, go o, por supuesto, node. Esto lo que haría sería automáticamente establecer un preset de targets que suelan ser frecuentes en dichos ecosistemas. De este modo se reduciría —creo— al mínimo la fricción con los usuarios. Adicionalmente para el ecosistema web/node, ya no solo se limitarían a los mencionados node_modules, sin o que buscaría también en otros rincones como directorios de caché que también podrían llegar a ser muy pesados como .angular, .nex o .nx.

Un ejemplo que se me viene a la cabeza podría ser:

  • Python
    • __pycache__
    • .venv
    • env
  • Java
    • build
    • .grandle
    • .mvn
  • Dotnet
    • bin
    • obj
  • Unity
    • Library
    • Temp
    • Build

Por supuesto en caso de que esto siguiera adelante, tendríamos que ver muy bien qué directorios conformarían cada perfil para no propiciar que se pueda eliminar algo que no sea “basura”.

Identidad vs. Evolución

¿Buena idea? Desde luego, yo creo que si. Pero hay algo que me preocupa mucho, y es la personalidad de npkill.

Ya no sería

Easily find and remove old and heavy node_modules folders ✨

Sería algo como:

Easily find and remove old and heavy unnecesary artifact folders ✨

Este proyecto siempre ha sido, ante todo, una herramienta para lidiar con los node_modules y al fin y al cabo es su esencia. Su razón inicial de ser. ¿Hasta qué punto se estaría desplazando su valor principal? ¿Bastaría con dejar por defecto todo como está, y dejar estas nuevas posibilidades simplemente reflejadas en la documentación… para aquellos intrépidos exploradores que se las leen?

La llegada inminente de la primera major hace que sea el momento de introducir cambios importantes. Y aunque decir “ahora o nunca” suena un poco dramático, hay decisiones que, si no se toman en su momento, acaban arrastrándose para toda la vida.

¿Y tú que opinas? ¿Deberíamos expandir npkill y explorar nuevas fronteras o mantenernos fiel a sus orígenes y, si acaso, crear un nuevo proyecto independiente? Tus comentarios me importan muchísimo. Puedes unirte a la discusión o contactarme a través de alguna red social (links en el footer).