Revise un package.json como lo lee npm: nombre, versión, licencia, dependencias y sintaxis
Se ejecuta en su navegador. Nada de lo que escribe se envía a ningún sitio. Comprobado el 16 de octubre de 2026.Un validador de package.json revisa el archivo que npm lee antes de instalar o publicar un paquete. Pegue el archivo para ver los errores de sintaxis JSON con su línea, las advertencias exactas que imprime npm, si el nombre está permitido, si la licencia es uno de los 734 identificadores SPDX y las versiones de dependencias que no son rangos reales.
Esta página se ha traducido automáticamente del original en inglés. Ninguna persona ha revisado todavía la traducción, así que la versión en inglés es la que debe consultar. Leer el original en inglés
Pegue el package.json, abra el archivo o haga clic en Probar un ejemplo.
Corrija primero cualquier error de sintaxis JSON: se muestran su línea y su columna, con la causa habitual.
Lea lo que dice npm: las advertencias y errores que el propio npm imprime para este archivo, palabra por palabra.
Revise las comprobaciones adicionales, como dependencias sin versión fijada, y haga clic en Copiar informe para compartirlas.
npm lee package.json de forma estricta en algunos lugares y flexible en otros: una versión incorrecta lo detiene todo, mientras que una descripción ausente solo genera una advertencia. Esta página revisa el archivo en tres capas y muestra cada una por separado.
1. Sintaxis JSON. El primer error se muestra con su línea, su columna y la causa habitual: una coma final, un comentario, comillas simples o una clave sin comillas. También se listan las claves duplicadas, porque JSON.parse conserva en silencio solo la última y el primer valor se pierde.
2. Lo que dice npm. Las advertencias y errores que el propio npm imprime para este archivo, palabra por palabra, como "No repository field." o "Invalid version". Proceden de reescribir los propios normalize-package-data, validate-npm-package-name y validate-npm-package-license de npm, y las pruebas comparan las respuestas con esos paquetes en 80 archivos de muestra, 44 nombres y 54 cadenas de licencia.
| Mensaje de npm | Qué hacer |
|---|---|
| Invalid version: "1.0" | Escriba tres números, como 1.0.0 |
| No license field. | Añada "license": "MIT" u otro identificador SPDX |
| license should be a valid SPDX license expression | Use el identificador exacto, como Apache-2.0 |
| scripts['server'] should probably be scripts['start']. | Cambie el nombre del script a start |
| name can no longer contain capital letters | Use minúsculas en un paquete nuevo |
3. Comprobaciones adicionales. Dependencias escritas como *, latest o una cadena vacía; rangos de versión no válidos, comprobados con las mismas reglas que npm; un paquete listado a la vez en dependencies y devDependencies; dependencias git sin etiqueta; rutas locales en un paquete publicado; un "type" distinto de module o commonjs; rangos de engines; y el script de prueba de relleno que deja npm init.
Un archivo marcado con "private": true nunca se publica, así que npm no muestra sus advertencias; la página lo indica. Todo funciona en su navegador; nada de lo que pega se envía a ningún sitio.
El campo license debe ser un identificador SPDX exacto, como MIT, ISC o Apache-2.0, o una combinación como (MIT OR Apache-2.0). Las aproximaciones como "mit", "Apache 2.0" o "BSD" fallan. Para código cerrado escriba UNLICENSED, o SEE LICENSE IN LICENSE.txt para remitir a su propio archivo.
No en un paquete nuevo. Los nombres deben ir en minúsculas, tener como máximo 214 caracteres, ser seguros para URL, no empezar con punto ni guion bajo y no ser un módulo del núcleo de Node.js como http. Algunos paquetes antiguos tienen mayúsculas porque las reglas llegaron después, y npm todavía los instala, pero rechaza uno nuevo.
La versión debe ser una versión semántica completa con tres números, como 1.0.0 o 2.1.0-beta.1. Escribir 1.0, latest o una cadena vacía impide que npm lea el paquete. npm acepta una v inicial y la elimina, así que v1.2.3 se lee como 1.2.3.
Normalmente, sí. Ambos aceptan cualquier versión, así que dos instalaciones separadas por un mes pueden obtener versiones mayores distintas con cambios incompatibles. Escriba un rango con acento circunflejo como ^4.17.21, que acepta correcciones y funciones pero se detiene antes de la siguiente versión mayor, y confirme el archivo de bloqueo para que todas las instalaciones coincidan.
No. package.json es JSON estricto, que no tiene comentarios, así que una línea con // o /* impide que npm lea el archivo. Una solución habitual es una clave llamada "//" con un valor de cadena; npm ignora las claves que no conoce. La comprobación de sintaxis de esta página señala la línea del comentario.
npm avisa cuando package.json no tiene repository, porque el sitio web de npm enlaza al código fuente a partir de él. Añada "repository": {"type": "git", "url": "git+https://github.com/user/repo.git"}. La advertencia no detiene nada, y npm la omite por completo en un paquete marcado con "private": true.
Los tipos y las normas cambian; consulte la fuente antes de fiarse de una cifra.
¿Sigue sin resolverlo? Pregunte sobre Validador de package.json y cualquiera que lo sepa puede responder. No se necesita cuenta.