Aller au contenu
TextArray1.41.0
Tout en local

Analyseur de statistiques webpack

Découvrez quels packages et modules prennent le plus de place dans votre build webpack.

Entrée
Sortie
Outils connexes
Analyseur de taille JSONnouveauOutils de développement
Aperçu des dépendances du package.jsonnouveauOutils de développement
Calculateur de taille de compressionnouveauOutils de développement
différence de clé i18nOutils de développement
Convertisseur TOML en JSONOutils de développement
SQL vers JSONOutils de développement
Analyseur de statistiques webpack
Générez un stats.json depuis webpack (`webpack --json > stats.json`, ou avec `stats: { modules: true }` dans votre config) et collez-le ici pour voir exactement quels packages et modules gonflent votre build. C'est le moyen le plus rapide de répondre à « pourquoi mon build est-il si volumineux » sans installer un plugin bundle-analyzer ou recompiler avec des flags spéciaux — le rapport lit le JSON que vous avez déjà.
Groupez le rapport par package node_modules pour voir le coût total d'une dépendance, par dossier pour voir quelle partie de votre code source est la plus lourde, ou laissez-le non groupé pour inspecter les modules individuels un par un. L'option « lignes à afficher » limite un long rapport aux plus gros consommateurs; le pourcentage du total met la taille de chaque ligne en perspective; et si votre stats.json contient un champ de taille comprimée par module (gzipSize ou sizeGzip), l'activation de la colonne affiche les deux nombres côte à côte. Le filtrage par point d'entrée ou nom de chunk limite tout à un seul bundle, ce qui est utile quand une application a plus d'un fichier de sortie.
L'outil signale aussi les packages qui apparaissent à plus d'un chemin d'installation node_modules — un signe courant que deux dépendances demandent des versions incompatibles de la même bibliothèque et webpack termine par en embarquer deux copies. Ces lignes sont marquées dans la sortie pour être faciles à repérer même dans un long rapport. Choisissez un format tableau pour un rapport lisible ou CSV pour coller dans une feuille de calcul si vous suivez la taille du bundle dans le temps.
Tout s'exécute dans votre navigateur : le stats.json est analysé localement et n'est jamais uploadé nulle part, c'est donc sûr pour une base de code propriétaire. Copiez le résultat, téléchargez-le en fichier .txt, ou envoyez-le directement à l'entrée d'un autre outil pour continuer.
FAQ
Comment générer un stats.json?
Exécutez votre build webpack avec `webpack --json > stats.json`, ou ajoutez `stats: { modules: true }` à votre config webpack pour que le compilateur imprime les données des modules. L'outil a besoin d'un array "modules" au niveau supérieur pour fonctionner.
Qu'affiche le groupage par package que le groupage par dossier ne montre pas?
Le groupage par package condense tous les fichiers sous node_modules/react (par exemple) en une seule ligne, pour que vous voyiez l'empreinte totale d'une dépendance. Le groupage par dossier rapporte plutôt vos propres répertoires de code source, ce qui est plus utile pour trouver une fonction surdimensionnée dans votre propre code.
Pourquoi signale-t-il des packages « en doublon »?
Quand deux dépendances demandent chacune une version différente de la même bibliothèque, npm ou yarn peuvent imbriquer une deuxième copie dans node_modules au lieu de la dédupliquer. Cet outil détecte un nom de package qui apparaît à plus d'un chemin d'installation et le signale, car supprimer le doublon est souvent un moyen facile de réduire la taille du bundle.
Affiche-t-il les vraies tailles gzip si mon stats.json ne les inclut pas?
Non. La taille comprimée n'est affichée que si votre stats.json contient déjà un champ gzipSize ou sizeGzip par module — l'outil ne comprime jamais rien par lui-même, car cela signifierait relancer une étape de build. Sans ce champ, la colonne affiche un tiret.
Mon stats.json est-il uploadé quelque part?
Non. L'analyse et la compilation s'exécutent entièrement dans votre navigateur — le fichier ne quitte jamais votre appareil.