Votre code obfusqué par VM lève une exception à l'exécution - il peut s'agir d'une RangeError: Invalid array length, mais la même liste de contrôle s'applique aux autres erreurs inattendues qui n'apparaissent qu'après obfuscation. Suivez les étapes ci-dessous dans l'ordre. La première élimine de très loin la cause la plus fréquente ; les suivantes permettent de circonscrire un véritable bug.

Étape 1 - vérifier l'environnement d'exécution par rapport à l'option target

La cause la plus fréquente d'Invalid array length et d'erreurs similaires est une inadéquation entre l'option target et l'environnement dans lequel le code s'exécute réellement, combinée à vmSelfDefending: true.

Environnements où cela se déclenche :

• Node.js (exécution directe du bundle obfusqué via node)
• Chrome / Chromium headless, PhantomJS
• Puppeteer, Playwright, Cypress, Selenium / ChromeDriver, Nightmare
• jsdom et autres émulations du DOM côté serveur
• tout environnement où les fonctions natives du navigateur ont été interceptées ou remplacées

Si votre environnement d'exécution figure dans cette liste, l'erreur correspond au fonctionnement prévu de la protection, ce n'est pas un bug. Choisissez la solution qui correspond à votre cas :

• Exécution volontaire sous Node.js (script côté serveur, outil en ligne de commande, processus principal Electron) : réglez target: 'node' lors de l'obfuscation. La couche d'auto-défense se calibrera pour Node plutôt que pour le navigateur.
• Exécution de tests automatisés / E2E sur un build obfusqué (Cypress, Playwright, Puppeteer, Selenium) : produisez un build de test distinct avec vmSelfDefending: false. Cette option est conçue pour casser l'automatisation ; elle ne peut pas être mise en liste blanche outil par outil. Consultez Auto-défense de la VM pour la liste complète des environnements incompatibles.
• Exécution dans un vrai navigateur mais l'erreur persiste : assurez-vous qu'aucune extension, aucun script de devtools ni aucune page englobante n'intercepte les fonctions natives (Array, Function.prototype, JSON, etc.). Reproduisez le problème dans un profil vierge avant de le considérer comme un bug.

Étape 2 - circonscrire le problème à une seule fonction

Si l'étape 1 n'a rien résolu, l'erreur se situe dans un morceau de code transformé bien précis. Passez à vmTargetFunctionsMode: 'comment' et ajoutez /* javascript-obfuscator:vm */ à une fonction à la fois jusqu'à ce que l'erreur réapparaisse. La fonction marquée au moment où l'erreur revient est la coupable - c'est le cas de reproduction minimal que vous enverrez au support.

Étape 3 - envoyer un rapport de bug

Une fois que vous avez écarté une inadéquation target/auto-défense et isolé une fonction, écrivez à support@obfuscator.io. Plus vous joindrez d'éléments parmi les suivants, plus vite nous pourrons corriger le problème :

• La trace d'appel complète de l'erreur, exactement telle qu'elle apparaît dans la console - pas une reformulation.
• Les options de l'obfuscateur au format JSON. Copiez l'intégralité de l'objet d'options utilisé (ou le nom du préréglage et vos éventuelles surcharges). Les interactions subtiles entre options sont fréquentes, nous avons donc besoin du jeu exact.
• La version de l'obfuscateur - affichée dans le coin inférieur droit de l'éditeur.
• L'environnement - navigateur et version, version de Node.js, système d'exploitation, ainsi que toute particularité de l'environnement d'exécution (extensions, polyfills, fonctions natives personnalisées).
• Une reproduction minimale - idéalement la seule fonction issue de l'étape 2, accompagnée du site d'appel nécessaire pour déclencher l'erreur.
• Le source original (avant obfuscation), dans la mesure du possible. La sortie obfusquée est également opaque de notre côté ; sans l'entrée, nous en sommes réduits à rétroconcevoir notre propre bytecode.