Verifique um package.json do jeito que o npm o lê: nome, versão, licença, dependências e sintaxe
Funciona no seu navegador. Nada do que você digita é enviado a lugar nenhum. Verificado em 16 de outubro de 2026.Um validador de package.json verifica o arquivo que o npm lê antes de instalar ou publicar um pacote. Cole o arquivo para ver erros de sintaxe JSON com a linha, os avisos exatos que o npm imprime, se o nome é permitido, se a licença é um dos 734 identificadores SPDX e versões de dependências que não são faixas reais.
Esta página foi traduzida automaticamente do original em inglês. Nenhuma pessoa revisou ainda a tradução; a versão em inglês é a que deve ser considerada. Ler o original em inglês
Cole o package.json, abra o arquivo ou clique em Testar um exemplo.
Corrija primeiro qualquer erro de sintaxe JSON: a linha e a coluna aparecem, com a causa mais comum.
Leia o que o npm diz: os avisos e erros que o próprio npm imprime para este arquivo, palavra por palavra.
Passe pelas verificações extras, como dependências sem versão fixada, e clique em Copiar relatório para compartilhá-las.
O npm lê o package.json de forma rígida em alguns pontos e flexível em outros: uma versão errada trava tudo, enquanto uma descrição ausente só gera um aviso. Esta página verifica o arquivo em três camadas e mostra cada uma separadamente.
1. Sintaxe JSON. O primeiro erro aparece com a linha, a coluna e a causa mais comum: uma vírgula sobrando no final, um comentário, aspas simples ou uma chave sem aspas. Chaves duplicadas também são listadas, porque o JSON.parse mantém em silêncio só a última e o primeiro valor se perde.
2. O que o npm diz. Os avisos e erros que o próprio npm imprime para este arquivo, palavra por palavra, como "No repository field." ou "Invalid version". Eles vêm de uma reescrita dos próprios normalize-package-data, validate-npm-package-name e validate-npm-package-license do npm, e os testes comparam as respostas com esses pacotes em 80 arquivos de exemplo, 44 nomes e 54 textos de licença.
| Mensagem do npm | O que fazer |
|---|---|
| Invalid version: "1.0" | Escreva três números, como 1.0.0 |
| No license field. | Adicione "license": "MIT" ou outro identificador SPDX |
| license should be a valid SPDX license expression | Use o identificador exato, como Apache-2.0 |
| scripts['server'] should probably be scripts['start']. | Renomeie o script para start |
| name can no longer contain capital letters | Use letras minúsculas em um pacote novo |
3. Verificações extras. Dependências escritas como *, latest ou texto vazio; faixas de versão inválidas, verificadas com as mesmas regras do npm; um pacote listado ao mesmo tempo em dependencies e devDependencies; dependências git sem tag; caminhos locais em um pacote publicado; um "type" diferente de module ou commonjs; faixas de engines; e o script de teste provisório que o npm init deixa.
Um arquivo marcado com "private": true nunca é publicado, então o npm não mostra os avisos dele; a página informa isso. Tudo roda no seu navegador; nada do que você cola é enviado para lugar algum.
O campo license precisa ser um identificador SPDX exato, como MIT, ISC ou Apache-2.0, ou uma combinação como (MIT OR Apache-2.0). Quase acertos como "mit", "Apache 2.0" ou "BSD" falham. Para código fechado escreva UNLICENSED, ou SEE LICENSE IN LICENSE.txt para apontar para o seu próprio arquivo.
Não em um pacote novo. Os nomes precisam estar em minúsculas, ter no máximo 214 caracteres, ser seguros para URL, não começar com ponto nem sublinhado e não ser um módulo nativo do Node.js como http. Alguns pacotes antigos têm maiúsculas porque as regras vieram depois, e o npm ainda os instala, mas recusa um novo.
A versão precisa ser uma versão semântica completa com três números, como 1.0.0 ou 2.1.0-beta.1. Escrever 1.0, latest ou um texto vazio impede o npm de ler o pacote. O npm aceita um v no início e o remove, então v1.2.3 é lido como 1.2.3.
Normalmente, sim. Os dois aceitam qualquer versão, então duas instalações com um mês de diferença podem pegar versões principais diferentes com mudanças incompatíveis. Escreva uma faixa com circunflexo como ^4.17.21, que aceita correções e recursos mas para antes da próxima versão principal, e faça commit do arquivo de lock para que toda instalação seja igual.
Não. O package.json é JSON estrito, que não tem comentários, então uma linha com // ou /* impede o npm de ler o arquivo. Uma saída comum é uma chave chamada "//" com um valor de texto; o npm ignora chaves que não conhece. A verificação de sintaxe desta página aponta a linha do comentário.
O npm avisa quando o package.json não tem repository, porque o site do npm usa esse campo para linkar o código-fonte. Adicione "repository": {"type": "git", "url": "git+https://github.com/user/repo.git"}. O aviso não trava nada, e o npm o omite totalmente em um pacote marcado com "private": true.
Taxas e regras mudam; confira a fonte antes de confiar em um valor.
Ainda com dúvidas? Pergunte sobre Validador de package.json e qualquer pessoa que saiba pode responder. Não é preciso ter conta.