El misterio de `--save` en npm install: ¿Todavía lo necesitas?

A ver, seamos directos. Si llevas un tiempo en el mundo JavaScript, es muy probable que cada vez que instalabas un paquete con npm, escribieras algo como npm install mi-paquete --save. Yo mismo lo hice por años. Lo vi en cuanto tutorial existía, y se convirtió en un hábito casi automático. Pero te tengo una noticia, y puede que te vuele un poco la cabeza: esa bandera --save ya no es necesaria, y de hecho, usarla ahora mismo es como apretar el embrague en un auto automático. Es decir, no te hace mal, pero tampoco hace nada.

Esto me genera una pequeña frustración, porque veo mucha gente, incluso juniors, aprendiendo a usar una sintaxis que ya está obsoleta para su propósito principal. Y lo peor es que si no entiendes el porqué detrás, puedes terminar con un package.json que no refleja bien las necesidades de tu proyecto.

El Origen: Cuando `npm install` no era tan listo

Para entender por qué --save existió, tenemos que viajar un poco al pasado de npm, antes de la versión 5. En esos días, cuando tú ejecutabas un simple npm install mi-paquete, npm hacía exactamente eso: instalaba el paquete dentro de la carpeta node_modules de tu proyecto. Fin. No hacía más.

El problema es que para que tu proyecto fuera reproducible, y para que otras personas pudieran instalar todas las dependencias con un simple npm install, tenías que registrar ese paquete y su versión en el archivo package.json, específicamente en la sección de dependencies. Esto significaba que, después de instalar, tenías que abrir tu package.json y añadir manualmente:

  "dependencies": {
    "mi-paquete": "^1.2.3"
  }

Imagínate haciendo esto por cada dependencia. Era un dolor de cabeza y una fuente de errores tremenda. Aquí es donde entra en juego --save.

La Solución Temporal: `--save` al Rescate

La opción --save nació para automatizar ese paso. Cuando ejecutabas npm install mi-paquete --save, npm no solo instalaba el paquete en node_modules, sino que también lo agregaba automáticamente a la sección dependencies de tu package.json con la versión correcta. Era una maravilla, una simplificación que te ahorraba un montón de tiempo y posibles metidas de pata. De hecho, por mucho tiempo, yo mismo les decía a mis clientes: “siempre usa --save, así no se te olvida nada”. ¡Vaya uno a saber!

Pero la historia no termina ahí. No todas las dependencias son iguales. Hay paquetes que tu aplicación necesita para funcionar en producción (como Express o React), y hay otros que solo son necesarios durante el desarrollo o para la construcción del proyecto (como un compilador de SASS, un linter o una librería de tests). Para esto, npm introdujo otras opciones:

• --save-dev: Agregaba el paquete a devDependencies. Es para las herramientas que solo usas mientras desarrollas o para construir tu aplicación.
• --save-optional: Agregaba el paquete a optionalDependencies. Son dependencias que, si fallan al instalar, no impiden que la aplicación principal funcione. Son más raras de usar, la verdad.

Esto es crucial. Recuerdo una vez, hace unos años, tuve un PR rechazado por un colega por un tema de devDependencies. Había añadido una librería de testing con --save a secas, y terminó en las dependencies de producción. El problema era que esa librería sumaba unos cuantos megabytes al bundle final que se desplegaba, lo que significaba tiempos de descarga más lentos para los usuarios. Mi colega, con mucha razón, me dijo: “Jorge, ¿por qué estoy desplegando tu suite de tests a los clientes?”. Me sentí un poco tonto, pero aprendí la lección a las malas: entender la diferencia entre dependencies y devDependencies es fundamental para no hinchar tu aplicación con cosas innecesarias.

El Gran Cambio: npm 5 y el Fin de `--save`

Con la llegada de npm 5.0.0 en mayo de 2017, el comportamiento predeterminado de npm install cambió. A partir de esa versión, cuando ejecutas:

npm install mi-paquete

npm automáticamente instala el paquete y lo añade a la sección dependencies de tu package.json. ¡Así de simple! La bandera --save se volvió redundante para este propósito.

Esto simplifica las cosas, claro. Pero lo que me cuesta entender es por qué la costumbre persiste. Hay tutoriales nuevos que todavía lo incluyen, y de hecho, no hace mucho vi a un desarrollador junior en mi equipo usando --save de forma religiosa. Le expliqué que no era necesario, y se sorprendió. No es que sea un error crítico, pero es una de esas cosas que, si no te actualizas, te quedas usando herramientas de forma subóptima.

Ojo, que las otras opciones, --save-dev y --save-optional (o sus atajos -D y -O), siguen siendo importantes y necesarias. Si quieres añadir un paquete a tus dependencias de desarrollo, todavía tienes que ser explícito:

npm install mi-paquete-dev --save-dev
# O su versión corta
npm install mi-paquete-dev -D

Esto asegura que tu package.json esté limpio y correctamente categorizado, lo que es vital para despliegues eficientes y para que tu equipo entienda las dependencias de tu proyecto. En mi caso, yo siempre uso -D para las dependencias de desarrollo. Me ahorra un par de caracteres y hace el comando más legible, creo yo.

¿Qué haría diferente si empezara de cero?

Si tuviera que empezar mi camino en el desarrollo con Node.js y npm hoy, haría una cosa muy diferente: me obligaría a entender a fondo package.json y el propósito de cada sección antes de tocar un solo comando de npm install. En mis inicios, yo simplemente copiaba y pegaba comandos, sin entender realmente qué hacía cada parte.

Creía que npm install --save era una regla de oro inmutable, cuando en realidad era una solución para un problema que ya no existe gracias a la evolución de la herramienta. Habría invertido tiempo en leer la documentación oficial de npm, que, aunque a veces un poco densa, es la fuente más fidedigna y actualizada. No me habría fiado tanto de tutoriales viejos o de la inercia de la comunidad. Aprender los fundamentos primero te ahorra dolores de cabeza a largo plazo y te da una base sólida para adaptarte a los cambios que, te aseguro, seguirán llegando.