Diff package.json : comparer les manifestes npm en ligne
Collez l'ancien package.json à gauche, le nouveau à droite, et voyez exactement quelles dépendances, scripts et engines ont changé. Tourne dans votre navigateur, rien ne part ailleurs.
Ce qu'est cet outil de diff package.json
Un outil gratuit qui tourne dans le navigateur pour comparer deux fichiers npm package.json côte à côte. Collez l'ancien manifeste à gauche, le nouveau à droite, et les différences se surlignent caractère par caractère. Le texte ne quitte jamais votre machine, ce qui compte quand le manifeste appartient à un dépôt privé ou à un produit pas encore sorti.
Il est fait pour le moment où une PR Renovate ou Dependabot arrive et où vous devez savoir ce qui a vraiment changé au-delà des bumps de version. Quelqu'un a-t-il glissé une modif de script ? Le champ engines est-il passé de Node 18 à Node 20 ? Une peerDependency a-t-elle été resserrée ? La vue de diff de GitHub répond en partie, mais coller deux manifestes dans une vue propre à deux panneaux est plus rapide quand vous parcourez plusieurs PRs d'affilée ou comparez des branches pas encore poussées.
Sous le capot, c'est le même diff conscient de JSON qui anime notre page compare-json, avec un cadrage et un texte calés pour les workflows npm et yarn. Les deux manifestes sont parsés en JSON et reformatés avant que le diff tourne, donc les différences cosmétiques d'espaces ne polluent pas le surlignage. Si vous avez besoin d'un diff de texte brut pour un format de manifeste non-JSON, notre outil compare-text couvre ça, et compare-yaml gère pnpm-lock.yaml.
Comment le diff fonctionne réellement
Chaque panneau est parsé en JSON. Si le parsing réussit, le manifeste est reformaté avec une indentation de deux espaces cohérente et l'ordre des clés est préservé tel qu'écrit. Si le parsing échoue (une virgule en trop, une accolade manquante, un copier-coller qui a pris trop peu de caractères) l'outil bascule en mode texte brut et vous indique quelle ligne a cassé. Une fois les deux côtés en JSON valide, le diff tourne caractère par caractère, puis une passe de nettoyage sémantique regroupe les changements en blocs lisibles, donc un bump de version de ^18.2.0 à ^19.0.0 se lit comme une seule édition, pas neuf éditions de caractères.
Les insertions dans le panneau de droite s'affichent en vert ; les suppressions dans le panneau de gauche s'affichent en rouge. Les deux panneaux sont synchronisés au défilement, donc quand vous trouvez un changement enfoui dans devDependencies d'un côté, l'autre saute à la même clé. Comme le diff est au niveau du texte après reformatage, il voit les changements structurels comme un humain les lit : une dépendance supprimée disparaît en tant que ligne, une plage semver modifiée se surligne dans la valeur, un nouveau script s'insère dans le bloc scripts à la position où vous l'avez placé.
Ce que l'outil ne fait délibérément pas : ce n'est pas un résolveur de dépendances. Il ne vous dira pas quels paquets transitifs un bump de plage caret entraîne, si un peer est satisfait, ou si la nouvelle version introduit un avis de sécurité. Pour ça, lancez npm install suivi de npm audit en local, ou utilisez npm avec un service qui comprend les lockfiles comme Snyk ou les alertes Dependabot de GitHub. Cette page vous dit ce que dit le texte du manifeste. Le travail de résolution revient à votre gestionnaire de paquets.
Comment differ un package.json en trois étapes
Deux panneaux de texte, un diff. Pas de flags CLI, pas d'étape d'installation, pas de format patch à lire.
- 1
Collez l'ancien manifeste à gauche
Copiez la version précédente de package.json depuis votre éditeur, depuis git show main:package.json, ou depuis un collègue. Collez dans le panneau de gauche. L'outil le parsera en JSON et le reformatera ; si le JSON est invalide, l'éditeur affichera l'erreur de parsing pour que vous corrigiez le snippet avant de differ.
- 2
Collez le nouveau manifeste à droite
Faites pareil avec la version mise à jour. Si vous relisez une PR Renovate ou Dependabot, la source la plus simple est le fichier brut depuis la branche de la PR. Les deux fichiers sont reformatés avec une indentation cohérente, donc les modifs cosmétiques d'espaces n'apparaîtront pas comme de faux changements dans le diff.
- 3
Lisez les différences surlignées
Les suppressions apparaissent en barré rouge à gauche ; les insertions apparaissent en vert à droite. Parcourez d'abord les blocs de dépendances, puis vérifiez la section scripts pour les modifs de commandes, puis les champs engines et peerDependencies. Les bumps de version dans une seule valeur surlignent les caractères modifiés, pour que vous distinguiez un bump de patch d'un majeur d'un coup d'œil.
Quand un diff de package.json est le bon réflexe
Relire une PR Renovate ou Dependabot
Un bot ouvre quinze PRs en une matinée. La plupart sont routinières, mais une a glissé un changement de script, ou une peerDependency resserrée, ou un bump engines qui casse votre image CI. Le titre de la PR dit "chore(deps): bump foo from 4.1.0 to 4.2.1" et vous faites confiance en pilote automatique. Collez les package.json avant et après dans le diff et vous pouvez vérifier en cinq secondes que rien d'autre n'a bougé. C'est la raison la plus fréquente pour laquelle les ingénieurs JS sortent un diff de manifeste.
Comparer deux branches avant de merger
Vous et un collègue avez tous les deux touché à package.json sur des branches feature séparées. Git fusionnera proprement parce que les modifs sont dans des blocs différents, mais un merge propre ne veut pas dire un merge correct. Collez les manifestes des deux branches dans le diff pour repérer un script qu'une branche a supprimé, une dépendance qu'une branche a downgradée, ou un conflit où les deux branches ont ajouté le même paquet en versions différentes. Moins coûteux que de le découvrir après que la CI ait lancé npm ci contre le résultat fusionné.
Auditer ce que npm install a promu dans package-lock.json
Éditer package.json est la moitié du changement. L'autre moitié est ce que package-lock.json enregistre sur l'arbre résolu. Après avoir lancé npm install, collez l'ancien lockfile à côté du nouveau pour voir quels paquets transitifs sont venus pour la balade. Les ajouts surprises sont fréquents quand une plage caret a entraîné un nouveau minor d'une dépendance profondément imbriquée. Pour l'inspection brute de lockfile notre page compare-json gère mieux les gros fichiers ; cette page est meilleure pour le manifeste lui-même.
Vérifier un downgrade après une régression
Une release sort, un bug apparaît, vous bisectez, et le suspect est quelque part dans l'arbre de dépendances. Collez le package.json de la dernière bonne release à côté de l'actuel. Mentalement, écartez les blocs inchangés et concentrez-vous sur les plages de versions surlignées. La correction est souvent un downgrade d'une bibliothèque vers la version épinglée dans le dernier build vert. Une fois le suspect trouvé, verrouillez-le avec une version exacte (sans caret, sans tilde) jusqu'à ce que le problème upstream soit résolu.
Comparer votre manifeste local à celui d'un collègue
Deux ingénieurs, un merge délicat, deux fichiers package.json différents en bout de rebase. Le lockfile est encore plus embrouillé. Collez les deux manifestes côte à côte pour voir quelles clés divergent, puis résolvez-les délibérément plutôt qu'accepter le résultat de git merge -X theirs sans le lire. C'est aussi le bon outil quand vous accueillez un nouveau contributeur dont npm install récupère un arbre différent du vôtre et que vous suspectez une dérive de manifeste.
Revue pré-publish du package.json d'une bibliothèque
Avant de lancer npm publish sur une bibliothèque, les champs du manifeste qui comptent sont différents de ceux d'une app : main, module, types, exports, files, peerDependencies, engines. Diffez le manifeste sur le point d'être publié contre le dernier publié. Une entrée peerDependencies supprimée, une condition exports changée, ou une plage engines resserrée peuvent casser les consommateurs de manières que npm lui-même ne signalera pas. La doc des packages Node.js est la référence pour ce que ces champs signifient.
Champs de package.json à connaître
Les champs qui apparaissent dans de vrais diffs de package.json et ce qu'ils signifient. À parcourir avant de valider une PR Renovate ou de merger deux branches qui ont toutes deux touché au manifeste.
| Topic | What this tool does |
|---|
| dependencies vs devDependencies vs peerDependencies | dependencies sont expédiées avec votre paquet et installées par quiconque le consomme. devDependencies ne sont installées que quand vous lancez npm install à la racine du projet, jamais pour les consommateurs en aval. peerDependencies sont des paquets que votre bibliothèque attend que l'hôte fournisse (typiquement React, le framework de tests, le bundler) et npm 7+ les installera automatiquement sauf conflit. Déplacer un paquet entre ces blocs change qui paie le coût d'installation. |
|---|
| Plages semver caret (^) vs tilde (~) | Le caret ^1.2.3 autorise toute version jusqu'à mais sans inclure 2.0.0 ; c'est le défaut npm et la plage commune la plus large. Le tilde ~1.2.3 n'autorise que les patches, jusqu'à mais sans inclure 1.3.0. 1.2.x équivaut au tilde. * signifie n'importe quelle version (à ne pas utiliser en production). latest se résout au moment de l'installation et produit des builds non reproductibles, donc à éviter. |
|---|
| Épinglage exact (sans préfixe de plage) | Écrire "react": "18.2.0" sans caret ni tilde épingle à cette version exacte. Combiné à un lockfile, ça vous donne l'installation la plus reproductible au prix de ne jamais recevoir les patches de sécurité automatiquement. Certaines équipes épinglent tout ; d'autres s'appuient sur la combinaison caret plus lockfile. Il n'y a pas de réponse universellement bonne, mais le compromis est plus de builds déterministes contre des dépendances plus obsolètes. |
|---|
| Déterminisme de package-lock.json | package-lock.json enregistre la version résolue exacte de chaque paquet de l'arbre de dépendances, transitives incluses. npm ci installe depuis le lockfile et refuse de le modifier ; npm install peut le mettre à jour si une plage autorise une version plus récente. Pour la CI, utilisez toujours npm ci. Pour les développeurs, npm install convient tant que vous commitez le changement de lockfile résultant. |
|---|
| Champ workspaces pour les monorepos | Le tableau workspaces dit à npm de traiter les répertoires frères comme des paquets liés dans un monorepo. npm install à la racine installe tous les workspaces et crée un unique arbre node_modules hoisté. Yarn et pnpm supportent les workspaces avec leurs propres conventions, et pnpm en particulier hoiste moins agressivement, ce qui attrape plus de bugs de fuite de dépendances au moment de l'installation. |
|---|
| Champ engines | engines.node déclare les versions de Node.js que votre paquet supporte. Par défaut npm avertit seulement quand l'hôte viole ça ; engine-strict=true dans .npmrc en fait une erreur dure. Bumper le champ engines est un changement cassant pour les consommateurs coincés sur du Node ancien, et c'est le genre de changement qui se cache dans une PR "chore" Renovate. Lisez toujours le diff engines. |
|---|
| Champ exports pour les ES modules | Le champ exports contrôle quels chemins les consommateurs peuvent importer de votre paquet et quelles conditions (import, require, types, node, browser) résolvent vers quels fichiers. Ajouter ou retirer une entrée est un changement cassant pour le code en aval. La documentation des packages Node.js couvre les règles de résolution en détail ; traitez tout diff exports comme une édition digne d'une version majeure sauf si vous ajoutez délibérément un nouveau point d'entrée. |
|---|
| Ordre des entrées dans package.json | Il n'y a pas d'ordre imposé pour les clés de premier niveau dans package.json. Par convention, la plupart des projets commencent par name, version, description, puis scripts, puis les dépendances. Dans les blocs de dépendances, l'ordre alphabétique par clé est le standard de fait et la plupart des gestionnaires de paquets trient le bloc à la sauvegarde. Un diff qui montre des entrées réordonnées mais par ailleurs identiques est en général une différence d'outillage, pas un vrai changement. |
|---|
Diff package.json : questions fréquentes
En quoi est-ce différent de npm diff ou npm-check-updates ?
npm diff est une commande npm intégrée qui compare deux versions publiées d'un paquet sur le registry, y compris leurs tarballs et sources. npm-check-updates (ncu) signale quelles dépendances de votre manifeste ont des versions plus récentes disponibles. Aucun ne vous montre la différence entre deux fichiers package.json arbitraires que vous avez sur disque ou dans deux branches. Cet outil le fait. Utilisez ncu pour savoir ce que vous devriez mettre à jour, npm diff pour voir les changements côté registry entre releases, et cette page pour relire votre propre manifeste avant et après dans une vue côte à côte.
Audite-t-il la sécurité ou vérifie-t-il les vulnérabilités connues ?
Non. Cette page ne fait que differ le texte. Elle n'interroge pas le registry npm, la GitHub Advisory Database, ni aucun service de vulnérabilités. Pour l'audit sécurité, lancez npm audit contre un arbre installé, utilisez npm audit signatures pour vérifier la provenance du paquet, ou appuyez-vous sur les alertes Snyk, Socket ou Dependabot. Cet outil est le bon choix quand vous voulez savoir ce qui a changé dans le manifeste. C'est le mauvais choix quand vous voulez savoir si le changement est sûr à expédier.
Détecte-t-il les changements de dépendances transitives ?
Pas depuis le manifeste seul. package.json liste seulement les dépendances directes et leurs plages demandées. L'arbre résolu complet, transitives incluses, vit dans package-lock.json (ou yarn.lock ou pnpm-lock.yaml). Pour comparer des arbres résolus, collez les deux lockfiles dans un diff. Comme les lockfiles sont gros, notre page compare-json les gère mieux que celle-ci. Pour pnpm-lock.yaml en particulier, utilisez compare-yaml. Cette page est optimisée pour le manifeste.
Comment comparer deux fichiers package-lock.json ?
Collez les deux lockfiles dans les panneaux comme vous le feriez pour un manifeste. L'outil les parsera en JSON, les reformatera et les differa. Notez que les lockfiles peuvent atteindre des milliers de lignes, donc le diff surligné peut être long. Concentrez-vous d'abord sur les entrées packages de premier niveau, puis sur les champs version. Pour des fichiers de plus d'environ cinq mille lignes, notre page compare-json convient mieux car elle est calibrée pour gérer de gros payloads JSON avec le même moteur.
Quelle est la différence entre les plages caret (^) et tilde (~) ?
Toutes deux sont des plages semver qui permettent des mises à jour sans éditer manuellement le manifeste. Le caret ^1.2.3 autorise toute version qui ne change pas le chiffre non-nul le plus à gauche, donc 1.2.3 jusqu'à 1.999.999 sont acceptés, mais 2.0.0 non. Le tilde ~1.2.3 est plus strict : il n'autorise que les patches, donc 1.2.3 jusqu'à 1.2.999 sont acceptés mais 1.3.0 non. Le caret est le défaut npm et la plage la plus large ; le tilde est ce que vous prenez quand une bibliothèque a un historique de casse en releases mineures.
Y a-t-il des limites de taille pour les gros lockfiles ?
En pratique oui. Le diff tourne dans votre navigateur, donc des entrées très grandes (un lockfile de 20 000 lignes d'un monorepo, par exemple) peuvent ralentir la page ou bloquer l'onglet selon la mémoire. Pour des manifestes et lockfiles d'app typiques jusqu'à quelques milliers de lignes par côté, le diff se complète quasi instantanément. Pour des fichiers plus gros, notre page compare-json est le meilleur point d'entrée. Si vous comparez régulièrement d'énormes lockfiles, envisagez de lancer git diff package-lock.json en local et de le piper dans un pager ; ce flux passe à l'échelle plus loin que tout outil de navigateur.
Confidentialité et fonctionnement
Vos manifestes ne quittent jamais votre navigateur. Le diff, le parsing JSON, le surlignage et le rendu tournent tous sur votre machine. Nous ne uploadons pas le texte, ne le loguons pas, et ne le passons à aucun service tiers. Ça compte spécifiquement pour le code propriétaire : coller le package.json d'une bibliothèque pas encore sortie ou le lockfile d'un dépôt privé dans un service cloud peut en soi violer la politique de gestion des données de votre employeur, surtout quand le manifeste nomme des paquets scopés internes, des hôtes de registry privés, ou des noms de produits en développement. Vérifier la promesse est direct. Ouvrez les DevTools du navigateur, passez à l'onglet Network, collez les deux manifestes et observez. Aucune requête sortante quand vous comparez. Le même modèle de confidentialité tient pour nos autres outils, dont compare-json, compare-yaml pour pnpm-lock.yaml, et git-diff-online pour la revue de code générale. Pour la spec sous-jacente, voyez la référence de configuration Yarn et la doc package.json de npm.