Cuando empezamos en el mundo del desarrollo con Node.js, una de las primeras dudas que surge es la diferencia entre instalar paquetes de manera local o global. A simple vista parece un detalle menor, pero elegir incorrectamente puede provocar errores difíciles de depurar, especialmente cuando trabajamos en equipo o desplegamos aplicaciones en producción. En Q2BSTUDIO, como empresa especializada en desarrollo de aplicaciones a medida, sabemos que una correcta gestión de dependencias es la base de proyectos sostenibles y escalables.
Node Package Manager (npm) es el gestor de paquetes por defecto de Node.js. Su función principal es instalar, actualizar y gestionar las librerías que nuestro código necesita. Sin embargo, npm puede colocar esos paquetes en dos ubicaciones distintas: dentro del directorio del proyecto (instalación local) o en una carpeta global del sistema (instalación global). Entender cuándo usar cada una es clave para evitar el clásico error 'Cannot find module'.
Instalación local: la opción por defecto y la más segura
Ejecutar npm install express dentro de la carpeta de tu proyecto descarga el paquete dentro de node_modules/ y lo registra en package.json dentro de la sección dependencies. Esto significa que cualquier persona que clone el repositorio solo necesita ejecutar npm install para obtener exactamente las mismas versiones. Esta práctica es obligatoria para todas las librerías que tu aplicación utiliza en tiempo de ejecución, ya sea un framework web, un cliente de base de datos o una librería de validación.
Imagina que desarrollas una API REST con Express y la subes a un repositorio. Si otro desarrollador clona el proyecto y Express está instalado globalmente en tu máquina, su terminal le devolverá un error porque no encuentra el módulo. Este problema se agrava en entornos de integración continua o despliegues en la nube, donde el sistema no tiene acceso a tus paquetes globales. Por eso, en Q2BSTUDIO recomendamos siempre instalar de forma local cualquier dependencia que el código necesite para funcionar, incluyendo aquellas relacionadas con infraestructura cloud AWS/Azure que uses desde el backend.
Instalación global: solo para herramientas de línea de comandos
Cuando usamos npm install -g nodemon, el paquete se instala en una ubicación del sistema (por ejemplo, /usr/local/lib/node_modules en Linux o %AppData%/npm en Windows). Esto permite ejecutar el comando nodemon desde cualquier terminal, independientemente del proyecto en el que estés trabajando. Los paquetes globales son útiles para herramientas que usamos durante el desarrollo, como typescript, eslint, pm2 o create-react-app. No deben ser librerías que tu aplicación importe con require() o import.
Un error habitual es instalar globalmente un paquete como Express o Axios pensando que así estará disponible en todos los proyectos. Esto funciona en tu máquina local, pero rompe la reproducibilidad del proyecto. En entornos profesionales, donde la integración con sistemas de ciberseguridad y BI/Power BI requiere consistencia, no podemos permitirnos dependencias ocultas.
¿Y qué pasa con npx?
Desde la versión 5.2 de npm, disponemos de npx, un ejecutor de paquetes que permite lanzar comandos sin necesidad de instalación global. Por ejemplo, npx create-react-app mi-app descarga temporalmente el paquete y lo ejecuta, sin dejarlo instalado de forma permanente. Esto es ideal para herramientas que usamos de manera esporádica, como generadores de proyectos o versiones específicas de un CLI. En Q2BSTUDIO utilizamos esta estrategia para mantener los entornos de desarrollo limpios, especialmente cuando trabajamos con agentes IA o soluciones de inteligencia artificial que requieren versiones concretas de librerías.
Decisión práctica: ¿local, global o npx?
La regla que aplicamos en nuestros proyectos es sencilla: pregúntate quién necesita el paquete. Si lo necesita la aplicación (porque tu código lo importa), instálalo de forma local. Si lo necesitas tú como desarrollador para ejecutar comandos en varios proyectos, instálalo de forma global. Y si solo lo vas a usar una vez o de manera ocasional, utiliza npx.
En el contexto de aplicaciones a medida, esta distinción cobra aún más relevancia. Cuando construimos software personalizado para clientes, la gestión de dependencias debe estar documentada y ser replicable. Un package.json bien configurado evita sorpresas en entornos de staging y producción. Además, al integrar servicios cloud como AWS o Azure, las librerías de conexión (por ejemplo, aws-sdk) siempre deben ser locales.
Conclusión
Dominar la diferencia entre paquetes locales y globales no es solo una cuestión técnica, sino de organización y buenas prácticas. Te ahorrará horas de debugging y facilitará el trabajo en equipo. En Q2BSTUDIO, cada proyecto que desarrollamos sigue estos principios, combinando una base sólida de dependencias con el uso inteligente de herramientas globales y npx. Si estás empezando en Node.js, recuerda: instala local lo que tu código necesita, global lo que tu terminal necesita, y usa npx para el resto.
