Vérifiez un package.json comme npm le lit : nom, version, licence, dépendances et syntaxe
Fonctionne dans votre navigateur. Rien de ce que vous saisissez n'est envoyé nulle part. Vérifié le 16 octobre 2026.Un validateur de package.json vérifie le fichier que npm lit avant d'installer ou de publier un paquet. Collez le fichier pour voir les erreurs de syntaxe JSON avec leur ligne, les avertissements exacts qu'affiche npm, si le nom est autorisé, si la licence fait partie des 734 identifiants SPDX, et les versions de dépendances qui ne sont pas de vraies plages.
Cette page a été traduite automatiquement à partir de l'original anglais. Aucune personne n’a encore relu la traduction : c’est la version anglaise qui fait foi. Lire l'original en anglais
Collez le package.json, ouvrez le fichier ou cliquez sur Essayer un exemple.
Corrigez d'abord toute erreur de syntaxe JSON : sa ligne et sa colonne sont affichées, avec la cause habituelle.
Lisez ce que dit npm : les avertissements et erreurs que npm affiche lui-même pour ce fichier, mot pour mot.
Passez en revue les vérifications supplémentaires, comme les dépendances sans version figée, et cliquez sur Copier le rapport pour les partager.
npm lit package.json de façon stricte à certains endroits et souple à d'autres : une version incorrecte bloque tout, alors qu'une description absente ne vaut qu'un avertissement. Cette page vérifie le fichier en trois couches et affiche chacune séparément.
1. Syntaxe JSON. La première erreur est affichée avec sa ligne, sa colonne et la cause habituelle : une virgule finale, un commentaire, des guillemets simples ou une clé sans guillemets. Les clés en double sont aussi listées, car JSON.parse ne garde silencieusement que la dernière et la première valeur est perdue.
2. Ce que dit npm. Les avertissements et erreurs que npm affiche lui-même pour ce fichier, mot pour mot, comme "No repository field." ou "Invalid version". Ils proviennent d'une réécriture des modules normalize-package-data, validate-npm-package-name et validate-npm-package-license de npm, et les tests comparent les réponses avec ces paquets sur 80 fichiers d'exemple, 44 noms et 54 chaînes de licence.
| Message de npm | Que faire |
|---|---|
| Invalid version: "1.0" | Écrivez trois nombres, comme 1.0.0 |
| No license field. | Ajoutez "license": "MIT" ou un autre identifiant SPDX |
| license should be a valid SPDX license expression | Utilisez l'identifiant exact, comme Apache-2.0 |
| scripts['server'] should probably be scripts['start']. | Renommez le script en start |
| name can no longer contain capital letters | Utilisez des minuscules pour un nouveau paquet |
3. Vérifications supplémentaires. Les dépendances écrites *, latest ou chaîne vide ; les plages de versions invalides, vérifiées avec les mêmes règles que npm ; un paquet présent à la fois dans dependencies et devDependencies ; les dépendances git sans tag ; les chemins locaux dans un paquet publié ; un "type" autre que module ou commonjs ; les plages engines ; et le script de test factice que laisse npm init.
Un fichier marqué "private": true n'est jamais publié, donc npm reste muet sur ses avertissements ; la page le signale. Tout fonctionne dans votre navigateur ; rien de ce que vous collez n'est envoyé.
Le champ license doit être un identifiant SPDX exact, comme MIT, ISC ou Apache-2.0, ou une combinaison comme (MIT OR Apache-2.0). Les approximations comme "mit", "Apache 2.0" ou "BSD" échouent. Pour du code propriétaire, écrivez UNLICENSED, ou SEE LICENSE IN LICENSE.txt pour renvoyer à votre propre fichier.
Pas pour un nouveau paquet. Les noms doivent être en minuscules, faire au plus 214 caractères, être compatibles avec les URL, ne pas commencer par un point ou un tiret bas et ne pas être un module natif de Node.js comme http. Certains anciens paquets ont des majuscules parce que les règles sont venues après, et npm les installe toujours, mais il en refuse un nouveau.
La version doit être une version sémantique complète à trois nombres, comme 1.0.0 ou 2.1.0-beta.1. Écrire 1.0, latest ou une chaîne vide empêche npm de lire le paquet. npm accepte un v initial et le retire, donc v1.2.3 est lu comme 1.2.3.
En général, oui. Les deux acceptent n'importe quelle version, si bien que deux installations à un mois d'écart peuvent obtenir des versions majeures différentes avec des changements incompatibles. Écrivez une plage avec accent circonflexe comme ^4.17.21, qui prend les correctifs et les nouveautés mais s'arrête avant la version majeure suivante, et versionnez le fichier de verrouillage pour que chaque installation corresponde.
Non. package.json est du JSON strict, sans commentaires, donc une ligne // ou /* empêche npm de lire le fichier. Une parade courante est une clé nommée "//" avec une valeur texte ; npm ignore les clés qu'il ne connaît pas. La vérification de syntaxe de cette page pointe la ligne du commentaire.
npm avertit quand package.json n'a pas de repository, car le site de npm s'en sert pour lier le code source. Ajoutez "repository": {"type": "git", "url": "git+https://github.com/user/repo.git"}. L'avertissement ne bloque rien, et npm l'omet entièrement pour un paquet marqué "private": true.
Les taux et les règles changent ; vérifiez la source avant de vous fier à un chiffre.
Toujours bloqué ? Poser une question sur Validateur de package.json et toute personne qui connaît la réponse peut répondre. Aucun compte nécessaire.