Inspecteur de Bundle Webpack

Ce que cet outil vérifie

Une grande partie du web livre encore du code webpack, et sa structure mérite d'être comprise en tant que telle — indépendamment du graphe de dépendances général et agnostique du bundler que trace le Visualiseur de Dépendances de Bundle JS. Cet outil recherche spécifiquement les pièces d'un bundle webpack :

• L'amorçage runtime — la fonction en forme __webpack_require__ que tout build webpack embarque, détectée par le mécanisme exact qu'elle utilise pour invoquer un module (modules[moduleId].call(module.exports, module, module.exports, require)), et non par la recherche du nom littéral. Ce mécanisme survit au renommage complet des identifiants, il détecte donc toujours un build où tous les noms ont été minifiés.
• La carte des modules — soit sous la forme classique d'objet ({0: fn, 1: fn, ...}), soit sous la forme de tableau ([fn, fn, ...]) que les versions récentes de webpack utilisent par défaut.
• Les métadonnées chunk-push — pour les builds avec découpage de code, l'appel (self.webpackChunkXxx = self.webpackChunkXxx || []).push([[chunkIds], {modules}, runtime]), dont on extrait le nom et les ids du chunk.
• Les auxiliaires du runtime — lesquels parmi .m (carte des modules), .c (cache des modules), .d (define getter), .o (hasOwnProperty), .n (getter d'export par défaut), .s (id du module d'entrée) et .p (chemin public) sont présents.

Sélectionnez n'importe quel module dans la liste pour voir son vrai code source dans un panneau avec coloration syntaxique — sans rien exécuter, juste le texte que webpack lui-même a enroulé autour de ce module.

Quand ce n'est pas webpack

Si ni le runtime ni une carte des modules ne sont trouvés, l'outil indique « ceci ne ressemble pas à une sortie webpack » plutôt que de forcer une supposition, et ajoute un indice simple et honnête quand il y en a un — un commentaire //# sourceMappingURL=, ou le fait que le fichier soit analysé comme un module ES (fréquent pour les sorties Rollup, esbuild et Vite).

Limite connue

Un bundle passé par webpack puis par une seconde passe de minification plus agressive qui renomme aussi les noms de propriétés du runtime lui-même peut échapper à la vérification de forme .call() et être signalé comme non-webpack. C'est un compromis délibéré : un rare faux négatif vaut mieux qu'inventer une carte de modules qui n'existe pas réellement.

Confidentialité

Tout s'exécute dans votre navigateur via un vrai analyseur JavaScript (acorn). Le fichier que vous collez ou téléversez n'est jamais envoyé où que ce soit.