Qu'y a-t-il vraiment dans votre package.json ? Vérifiez avant de livrer
Votre `package.json` est sur le point d'atterrir sur npm. Ou dans la CI. Ou d'être collé dans un monorepo que personne n'a nettoyé depuis deux ans. La question : est-ce que ce fichier est vraiment OK ? Le name est-il valide, la version conforme à SemVer, avez-vous le même paquet à la fois dans `dependencies` et `devDependencies`, est-ce que `"react": "*"` va exploser au prochain npm install.
Vous collez tout le fichier dans la textarea. Le validateur fait quatre choses :
- vérifie si c'est du JSON valide tout court (bug le plus fréquent : virgule en trop après le dernier champ) ;
- valide le schéma npm : name conforme aux règles du registre, version conforme à SemVer, racine est un objet ;
- dessine un graphe de vos scripts : quel script appelle lequel (par ex. `build` appelle `clean` et `compile`), pour que vous voyiez immédiatement ce qui arrive quand vous lancez `npm run release` ;
- audite les dépendances : doublons entre deps et devDeps, jokers (`"*"`, `"latest"`), styles mixtes (`^` vs `~` vs versions exactes), peers manquants.
Tout s'exécute localement dans votre navigateur. Rien ne quitte la page, vous pouvez donc coller en toute sécurité le `package.json` de votre entreprise, personne hors de votre ordinateur ne voit les noms de dépendances, chemins de registre privé ou noms de scripts.
Comment l'utiliser
- Collez tout le `package.json` dans la grande textarea en haut. Si vous voulez juste voir comment ça marche, cliquez sur Load sample, le validateur chargera un exemple de paquet avec un problème intentionnellement laissé.
- La carte "Validity" affiche le résultat en vert ou rouge tout de suite. Vert = le JSON parse et le schéma npm est satisfait. Rouge = cliquez à travers la liste d'erreurs pour voir les choses précises à corriger.
- La carte "Metadata" affiche le name, version, type de module (ESM ou CommonJS), licence, repository dans une mise en page lisible au lieu que vous parcouriez le JSON brut.
- La carte "Scripts" dessine le graphe : quel script appelle lequel. Vous voyez `build` → `clean` + `compile` → `tsc`. Précieux sur un projet hérité avec 30 scripts.
- La carte "Dependencies" compte les paquets à travers quatre sections (deps / devDeps / peerDeps / optional) et liste les problèmes détectés : doublons, jokers, peers manquants, styles de version mixtes.
- La carte "Required fields" est une checklist verte ou ambrée : name, version, description, license, scripts, repository. Vous savez immédiatement ce qui manque avant que ce paquet puisse être publié sur npm.
- Cliquez sur Format si vous avez collé un `package.json` sur une seule ligne et voulez une sortie lisible à recopier.
Quand c'est utile
Cinq situations où le validateur vous économise une heure de débogage CI :
- Avant votre premier `npm publish`. Un paquet va sur npm pour la première fois. Le validateur vérifie si le name est valide (mauvais caractères = le registre rejette), si la version est SemVer, et si vous avez une licence. Sans lui, vous découvrez ça seulement après `npm publish` quand la publication échoue.
- Code review sur une pull request de monorepo. Quelqu'un a ajouté un paquet. Vous collez son `package.json` dans le validateur et voyez instantanément **`"react": "*"` dans deps**. Vous commentez la PR avant de merger quelque chose qui cassera à la prochaine mise à jour.
- Audit d'un projet que vous allez hériter. Vous reprenez un projet legacy où 47 scripts s'appellent les uns les autres. Le validateur dessine le graphe, vous voyez que `release` appelle `build`, qui appelle `compile`, qui appelle `tsc`. Une carte routière au lieu de lire 47 lignes de haut en bas.
- Comprendre pourquoi la CI échoue sur `npm ci`. Le build CI ne passe pas. Vous collez `package.json` et voyez : `package-x` est à la fois dans deps et devDeps, le lock-file s'embrouille, `npm ci` prend des versions différentes. Le validateur le fait remonter comme problème rouge.
- Migrer de npm vers pnpm ou yarn. Avant la migration, vous collez les deux fichiers `package.json` (ancien et nouveau) et vérifiez si les peer dependencies sont cohérentes, si les jokers ont disparu (pnpm est moins indulgent), et si les scripts forment un graphe sensé.
Questions et réponses
Non. Toute la validation tourne dans votre navigateur. Le fichier ne quitte jamais votre ordinateur, il n'y a pas d'API de l'autre côté. Vous pouvez coller en toute sécurité un `package.json` d'entreprise avec des noms de paquets privés, des chemins de registre internes, ou des noms de scripts comme `deploy-staging`. Le validateur marche 100 % offline après le premier chargement de la page, vous pouvez même vous déconnecter d'internet et ça marchera encore.