Collez un fichier de verrouillage ou un extrait pour lister les paquets reconnus et leurs versions résolues. Le rapport permet de repérer les paquets présents en plusieurs versions.
Fonctionne localement dans votre navigateurCette page lit package-lock.json, pnpm-lock.yaml ou yarn.lock dans le navigateur et indique ce que le fichier de verrouillage résout : combien d’entrées il fige, combien de noms différents il contient et quels noms sont figés sur plus d’une version. Rien n’est installé et aucun registre n’est contacté.
Collez le fichier ou une section, puis appuyez sur Analyser localement. Le rapport affiche le format détecté, le nombre d’entrées résolues et les noms en double ; le tableau donne le nom, la version et l’origine de chaque entrée, et Copier place le rapport JSON dans le presse-papiers.
Un fichier npm est reconnu à ses champs lockfileVersion, packages ou dependencies. Les fichiers de version 2 et 3 sont lus dans la table packages : chaque clé contenant node_modules/ devient une entrée, l’entrée du projet racine ("") n’est donc pas comptée et un chemin imbriqué comme node_modules/foo/node_modules/bar apparaît sous bar. Les fichiers de version 1 sont lus dans la table dependencies.
Un fichier pnpm est reconnu à son lockfileVersion ou à sa section packages, et chaque clé /nom@version devient une entrée, y compris les noms à portée comme /@babel/core@7.24.0. Un fichier Yarn classique est reconnu à ses blocs de sélecteurs : la ligne version est associée à chaque sélecteur de la clé, donc une ligne qui associe deux plages à une version produit deux entrées, et les sélecteurs entre guillemets comme "@scope/pkg@^0.4.0" sont débarrassés de leurs guillemets avant l’extraction du nom.
Une entrée est une résolution, pas un paquet distinct : chez npm un chemin de l’arbre, chez Yarn un sélecteur, si bien qu’une dépendance installée à deux niveaux apparaît deux fois. Le comptage des doublons travaille par nom sur les versions : un nom figé sur deux versions différentes est signalé, la même version atteinte par deux sélecteurs ne l’est pas.
Le rapport JSON contient format, resolvedPackages, uniqueNames et namesWithMultipleVersions et peut donc être comparé entre deux branches. Le tableau affiche au plus 500 lignes et le signale lorsque le fichier est plus grand ; les indicateurs et le rapport comptent toujours toutes les entrées.
Rien n’est téléchargé : la page ne contacte ni npm, ni le registre pnpm, ni Yarn, elle ne peut donc pas vérifier qu’une version existe, qu’un hash d’intégrité correspond ou qu’un paquet est obsolète ou concerné par un avis de sécurité. Une entrée sans champ version apparaît comme non résolue, ce qui indique en général un fichier modifié à la main ou écrit par un autre outil.
Un JSON mal formé arrête l’analyse avec une indication et la position de l’échec ; un YAML qui n’est pas un fichier pnpm et un JSON sans section de paquets reconnue répondent par le même message au lieu d’un tableau vide. Copier avant toute analyse renvoie une indication plutôt qu’un presse-papiers vide.