¿Qué hay realmente en tu package.json? Compruébalo antes de publicar
Tu `package.json` está a punto de aterrizar en npm. O en CI. O ser pegado en un monorepo que nadie ha limpiado en dos años. La pregunta: ¿el archivo está realmente bien?. ¿El nombre es válido? ¿La versión es SemVer correcta? ¿Tienes el mismo paquete en `dependencies` y `devDependencies`? ¿Volará `"react": "*"` la próxima vez que alguien ejecute npm install?
Pegas el archivo completo en el textarea. El validador hace cuatro cosas:
- comprueba si es JSON válido siquiera (bug más común: coma sobrante tras el último campo);
- valida el schema de npm: el nombre cumple las reglas del registry, la versión es SemVer, la raíz es un objeto;
- dibuja un grafo de tus scripts: qué script llama a cuál (p. ej. `build` llama a `clean` y `compile`), así ves al instante qué pasa cuando ejecutas `npm run release`;
- audita las dependencias: duplicados entre deps y devDeps, wildcards (`"*"`, `"latest"`), estilos mezclados (`^` vs `~` vs pins exactos), peers faltantes.
Todo se ejecuta localmente en tu navegador. Nada sale de la página, así que puedes pegar con seguridad el `package.json` de tu empresa: nadie fuera de tu ordenador ve los nombres de dependencias, rutas a registries privados o nombres de scripts.
Cómo se usa
- Pega el `package.json` completo en el textarea grande de arriba. Si solo quieres ver cómo funciona, pulsa Cargar muestra y se carga un paquete de ejemplo con un problema dejado a propósito.
- La tarjeta "Validez" muestra el resultado en verde o rojo al instante. Verde = el JSON parsea y el schema de npm se cumple. Rojo = revisa la lista de errores para ver qué arreglar.
- La tarjeta "Metadatos" muestra el nombre, versión, tipo de módulo (ESM o CommonJS), licencia y repositorio en un layout legible en lugar de escanear el JSON crudo.
- La tarjeta "Scripts" dibuja el grafo: qué script llama a cuál. Ves `build` → `clean` + `compile` → `tsc`. Impagable en un proyecto heredado con 30 scripts.
- La tarjeta "Dependencias" cuenta paquetes en cuatro secciones (deps / devDeps / peerDeps / optional) y lista problemas detectados: duplicados, wildcards, peers faltantes, estilos de versión mezclados.
- La tarjeta "Campos obligatorios" es una checklist verde o ámbar: nombre, versión, descripción, licencia, scripts, repositorio. Sabes al instante qué falta antes de publicar este paquete a npm.
- Pulsa Formatear si pegaste un `package.json` en una sola línea y quieres una salida legible para copiar.
Cuándo te resulta útil
Cinco situaciones donde el validador te ahorra una hora de depurar CI:
- Antes de tu primer `npm publish`. Un paquete va a npm por primera vez. El validador comprueba si el nombre es válido (caracteres prohibidos = el registry lo rechaza), si la versión es SemVer y si tienes licencia. Sin él te enteras al fallar el `npm publish`.
- Code review en una PR de monorepo. Alguien añadió un paquete. Pegas su `package.json` en el validador y ves al instante **`"react": "*"` en deps**. Comentas en la PR antes de mergear algo que se romperá en la próxima actualización.
- Auditoría de un proyecto que vas a heredar. Recibes un proyecto legado con 47 scripts llamándose entre sí. El validador dibuja el grafo y ves que `release` llama a `build`, que llama a `compile`, que llama a `tsc`. Un mapa en lugar de leer 47 líneas de arriba abajo.
- Entender por qué falla `npm ci` en CI. El build de CI no pasa. Pegas `package.json` y ves: `package-x` está en deps y devDeps a la vez, el lock-file se confunde, `npm ci` elige versiones distintas. El validador lo marca en rojo.
- Migrar de npm a pnpm o yarn. Antes de migrar pegas los dos `package.json` (el viejo y el nuevo) y compruebas si las peer dependencies son coherentes, si han desaparecido los wildcards (pnpm es menos indulgente) y si los scripts forman un grafo sensato.
Preguntas y respuestas
No. Toda la validación se ejecuta en tu navegador. El archivo no sale de tu ordenador, no hay API al otro lado. Puedes pegar con seguridad un `package.json` de empresa con nombres de paquetes privados, rutas a registries internos o nombres de scripts como `deploy-staging`. El validador funciona 100 % offline tras la primera carga; puedes incluso desconectar internet y seguirá funcionando.