En La terminal y npm creaste un package.json, instalaste un paquete y lanzaste un script.
package.json dice qué rangos de versión valen; package-lock.json, qué se instaló exactamente. Los dos van a Git.
^7.4.5 acepta cualquier 7.x desde la 7.4.5; ~7.4.5, solo parches.
npm ci reinstala exactamente lo del lock: para servidores y para clonar proyectos.
npm outdated, npm update y npm audit mantienen el proyecto al día y sin fallos conocidos.
En La terminal y npm creaste un package.json, instalaste un paquete y lanzaste un script. Cuando trabajes con Astro, Tailwind o cualquier proyecto que te pasen, vas a leer package.json ajenos, elegir versiones, reinstalar un proyecto en otro ordenador y publicarlo desde un servidor. Esta página es lo que necesitas para hacerlo sin romper el proyecto.
Así es el de un portafolio hecho con Astro:
{ "name": "portafolio-lucia", "type": "module", "version": "0.1.0", "private": true, "scripts": { "dev": "astro dev", "build": "astro build", "preview": "astro preview", "formato": "prettier --write ." }, "dependencies": { "astro": "^7.4.5" }, "devDependencies": { "prettier": "^3.9.10" }, "engines": { "node": ">=22.23" } }
CampoPara qué name, versionCómo se llama el proyecto y en qué versión va private: trueQue nunca se publique por error en el registro de npm type: "module"Que los .js usen import y export (el JavaScript de ahora) scriptsLos atajos que lanzas con npm run dependenciesLo que el proyecto necesita para construirse y funcionar devDependenciesHerramientas solo para trabajar: formatear, probar, revisar enginesQué versión de Node.js hace falta
En una web estática (como un portafolio con Astro) la diferencia entre dependencies y devDependencies importa poco: todo se usa al construir. Importa en proyectos que se ejecutan en un servidor, donde se instalan solo las dependencies.
Las versiones siguen el versionado semántico: mayor.menor.parche.
Parche (7.4.5 → 7.4.6): arreglos. No cambia nada de lo que usas. Menor (7.4 → 7.5): cosas nuevas, sin romper lo anterior. Mayor (7 → 8): cambios que pueden romper tu proyecto. Hay que leer la guía de cambio.
En package.json no se escribe una versión, sino un rango:
RangoAceptaEjemplo ^7.4.5Cualquier 7.x.x desde la 7.4.57.9.0 sí; 8.0.0 no ~7.4.5Solo parches de la 7.47.4.9 sí; 7.5.0 no 7.4.5Esa versión y ninguna otra ^0.4.2Por debajo de 1.0, solo la 0.4.x0.4.9 sí; 0.5.0 no
package.json dice qué rangos valen; package-lock.json dice qué versión exacta se instaló de cada paquete (y de los paquetes de los que dependen, que suelen ser cientos). Por eso se sube a Git: con él, tu compañero o el servidor instalan exactamente lo mismo que tú.
OrdenQué haceCuándo npm installInstala respetando el lock, y lo actualiza si añades o cambias algoMientras trabajas npm ciBorra node_modules e instala solo lo que dice el lock; si no cuadra con package.json, para con un errorEn un servidor, en GitHub Actions o al clonar un proyecto para revisarlo
Si algo se ha estropeado en node_modules, la solución no es borrar el lock: borra la carpeta node_modules y ejecuta npm ci.
OrdenPara qué npm install paqueteAñadir un paquete (-D si es una herramienta de trabajo) npm uninstall paqueteQuitarlo del proyecto y de package.json npm lsVer qué hay instalado (npm ls astro para uno solo) npm outdatedVer qué paquetes tienen versiones nuevas npm updateActualizar dentro de los rangos de package.json npm install paquete@latestPasar a la última versión, aunque sea un cambio mayor npm view paqueteVer la ficha de un paquete: versiones, licencia, repositorio npm auditBuscar fallos de seguridad conocidos en lo instalado npm runSin nombre de script, lista los que tiene el proyecto
npm outdated enseña tres columnas: Current (lo que tienes), Wanted (lo máximo que permite tu rango) y Latest (lo último publicado). Si Latest es una versión mayor, npm update no la va a instalar: es una decisión tuya.
Un script puede usar las herramientas instaladas en el proyecto sin npx: "formato": "prettier --write ." funciona porque npm busca prettier en node_modules/.bin. Para pasar opciones al programa, ponlas después de --: npm run dev -- --port 4000. Un script prebuild se ejecuta solo antes de build, y postbuild, después. npm start y npm test funcionan sin run; el resto, con npm run nombre.
Escribe los scripts para que funcionen en Windows, macOS y Linux: rm -rf no existe en la terminal de Windows. Si necesitas borrar o copiar, mejor una herramienta de npm que lo haga en todos.
Antes de instalar algo, mira su ficha en npmjs.com o con npm view:
Descargas semanales y última publicación: un paquete abandonado hace años es un riesgo. Repositorio y licencia: que exista el código y que puedas usarlo (MIT, ISC, Apache…). El nombre exacto: hay paquetes falsos con nombres casi iguales a los conocidos.
Algunos paquetes ejecutan código al instalarse. Por eso, ante algo raro, npm install no es inofensivo: lee lo que vas a instalar y ejecuta npm audit de vez en cuando. npm audit fix arregla lo que se puede arreglar sin cambiar de versión mayor.
Cada proyecto pide una versión mínima de Node.js (engines). En clase usamos la LTS, la de soporte largo: así en noviembre de 2026, Node.js 26, que trae npm 11. Si un proyecto necesita otra, un gestor de versiones (como fnm o nvm) instala varias y cambia de una a otra.
En la carpeta de tu portafolio (o en la carpeta prueba-npm de La terminal y npm):
Instala Prettier como herramienta de trabajo: npm install -D prettier. Añade el script "formato": "prettier --write ." y ejecútalo con npm run formato. Ejecuta npm outdated y apunta qué paquete tiene una versión nueva y si es parche, menor o mayor. Borra la carpeta node_modules y reinstala con npm ci. Comprueba que npm run dev sigue funcionando. Ejecuta npm audit y apunta cuántos avisos salen.
Borrar package-lock.json «para arreglar» algo: pierdes las versiones exactas. Borra node_modules. Usar npm install en el servidor de publicación: mejor npm ci, que falla si algo no cuadra. Actualizar a una versión mayor a ciegas con @latest justo antes de entregar. Instalar con -g lo que el proyecto necesita: otra persona no lo tendrá. Instálalo en el proyecto.
En La terminal y npm creaste un package.json, instalaste un paquete y lanzaste un script.
Código del tema: npm ci
En La terminal y npm creaste un package.json, instalaste un paquete y lanzaste un script. Cuando trabajes con Astro, Tailwind o cualquier proyecto que te pasen, vas a leer package.json ajenos, elegir versiones, reinstalar un proyecto en otro ordenador y publicarlo desde un servidor. Esta página es lo que necesitas para hacerlo sin romper el proyecto.
Así es el de un portafolio hecho con Astro:
{
"name": "portafolio-lucia",
"type": "module",
"version": "0.1.0",
"private": true,
"scripts": {
"dev": "astro dev",
"build": "astro build",
"preview": "astro preview",
"formato": "prettier --write ."
},
"dependencies": {
"astro": "^7.4.5"
},
"devDependencies": {
"prettier": "^3.9.10"
},
"engines": {
"node": ">=22.23"
}
}| Campo | Para qué |
|---|---|
name, version | Cómo se llama el proyecto y en qué versión va |
private: true | Que nunca se publique por error en el registro de npm |
type: "module" | Que los .js usen import y export (el JavaScript de ahora) |
scripts | Los atajos que lanzas con npm run |
dependencies | Lo que el proyecto necesita para construirse y funcionar |
devDependencies | Herramientas solo para trabajar: formatear, probar, revisar |
engines | Qué versión de Node.js hace falta |
En una web estática (como un portafolio con Astro) la diferencia entre dependencies y devDependencies importa poco: todo se usa al construir. Importa en proyectos que se ejecutan en un servidor, donde se instalan solo las dependencies.
Las versiones siguen el versionado semántico: mayor.menor.parche.
7.4.5 → 7.4.6): arreglos. No cambia nada de lo que usas.7.4 → 7.5): cosas nuevas, sin romper lo anterior.7 → 8): cambios que pueden romper tu proyecto. Hay que leer la guía de cambio.En package.json no se escribe una versión, sino un rango:
| Rango | Acepta | Ejemplo |
|---|---|---|
^7.4.5 | Cualquier 7.x.x desde la 7.4.5 | 7.9.0 sí; 8.0.0 no |
~7.4.5 | Solo parches de la 7.4 | 7.4.9 sí; 7.5.0 no |
7.4.5 | Esa versión y ninguna otra | |
^0.4.2 | Por debajo de 1.0, solo la 0.4.x | 0.4.9 sí; 0.5.0 no |
npm install paquete escribe ^ delante. Es lo normal: recibes arreglos y novedades, nunca un cambio mayor sin que lo pidas.
💡 Consejo. Para comprobar qué versiones entran en un rango, usa la calculadora de semver de npm (enlace en «Para saber más»).
package.json dice qué rangos valen; package-lock.json dice qué versión exacta se instaló de cada paquete (y de los paquetes de los que dependen, que suelen ser cientos). Por eso se sube a Git: con él, tu compañero o el servidor instalan exactamente lo mismo que tú.
| Orden | Qué hace | Cuándo |
|---|---|---|
npm install | Instala respetando el lock, y lo actualiza si añades o cambias algo | Mientras trabajas |
npm ci | Borra node_modules e instala solo lo que dice el lock; si no cuadra con package.json, para con un error | En un servidor, en GitHub Actions o al clonar un proyecto para revisarlo |
Si algo se ha estropeado en node_modules, la solución no es borrar el lock: borra la carpeta node_modules y ejecuta npm ci.
| Orden | Para qué |
|---|---|
npm install paquete | Añadir un paquete (-D si es una herramienta de trabajo) |
npm uninstall paquete | Quitarlo del proyecto y de package.json |
npm ls | Ver qué hay instalado (npm ls astro para uno solo) |
npm outdated | Ver qué paquetes tienen versiones nuevas |
npm update | Actualizar dentro de los rangos de package.json |
npm install paquete@latest | Pasar a la última versión, aunque sea un cambio mayor |
npm view paquete | Ver la ficha de un paquete: versiones, licencia, repositorio |
npm audit | Buscar fallos de seguridad conocidos en lo instalado |
npm run | Sin nombre de script, lista los que tiene el proyecto |
npm outdated enseña tres columnas: Current (lo que tienes), Wanted (lo máximo que permite tu rango) y Latest (lo último publicado). Si Latest es una versión mayor, npm update no la va a instalar: es una decisión tuya.
npx: "formato": "prettier --write ." funciona porque npm busca prettier en node_modules/.bin.--: npm run dev -- --port 4000.prebuild se ejecuta solo antes de build, y postbuild, después.npm start y npm test funcionan sin run; el resto, con npm run nombre.Escribe los scripts para que funcionen en Windows, macOS y Linux: rm -rf no existe en la terminal de Windows. Si necesitas borrar o copiar, mejor una herramienta de npm que lo haga en todos.
Antes de instalar algo, mira su ficha en npmjs.com o con npm view:
Algunos paquetes ejecutan código al instalarse. Por eso, ante algo raro, npm install no es inofensivo: lee lo que vas a instalar y ejecuta npm audit de vez en cuando. npm audit fix arregla lo que se puede arreglar sin cambiar de versión mayor.
Cada proyecto pide una versión mínima de Node.js (engines). En clase usamos la LTS, la de soporte largo: así en noviembre de 2026, Node.js 26, que trae npm 11. Si un proyecto necesita otra, un gestor de versiones (como fnm o nvm) instala varias y cambia de una a otra.
En la carpeta de tu portafolio (o en la carpeta prueba-npm de La terminal y npm):
npm install -D prettier."formato": "prettier --write ." y ejecútalo con npm run formato.npm outdated y apunta qué paquete tiene una versión nueva y si es parche, menor o mayor.node_modules y reinstala con npm ci. Comprueba que npm run dev sigue funcionando.npm audit y apunta cuántos avisos salen.package-lock.json «para arreglar» algo: pierdes las versiones exactas. Borra node_modules.npm install en el servidor de publicación: mejor npm ci, que falla si algo no cuadra.@latest justo antes de entregar.-g lo que el proyecto necesita: otra persona no lo tendrá. Instálalo en el proyecto.