Compatibilité d’exécution

target

• browser - Chrome, Firefox, Safari, Edge.
• browser-no-eval - identique à browser, mais la sortie n'utilise pas eval(). À utiliser lorsque la page cible applique une Content Security Policy qui interdit eval/unsafe-eval.
• node - environnement Node.js. Les options propres au navigateur sont désactivées (elles requièrent window/document et seraient sans effet ou lèveraient une erreur sous Node). Certaines défenses de vmSelfDefending qui reposent sur des API exclusivement navigateur - détection de navigateur headless, restauration d'un realm propre via iframe, contrôles anti-inspecteur/DOM - ne sont pas générées pour cette cible.
• service-worker - contexte Service Worker. Pas de window, pas de document, un global self différent.
• userscript - bac à sable d'un gestionnaire de userscripts (Tampermonkey, par exemple). Les défenses vmSelfDefending sont ajustées en conséquence. Nécessite l'obfuscateur v6.9.0+.
• bytenode - pour du code destiné à être compilé en .jsc avec bytenode. Nécessite l'obfuscateur v6.13.0+.

JavaScript

Les noms et le texte source des fonctions peuvent changer après obfuscation. N’utilisez pas .name ou .toString() comme données stables ; préférez des identifiants explicites. Les noms globaux publics peuvent rester visibles selon les réglages.

strictMode

strictMode: null et strictMode: false reconnaissent toujours les directives explicites, les modules ES et les méthodes de classe comme stricts. strictMode: true traite toute l’entrée comme stricte. Respectez le contexte final : un bundler ajoutant le mode strict après obfuscation peut modifier le comportement.

CLI / API

Compilez TypeScript ou JSX et regroupez l’application avant l’étape finale d’obfuscation. Conservez les commentaires de sélection VM jusque-là. Ne minifiez, reformatez ou modifiez plus une sortie auto-protégée. Les source maps sont indisponibles avec l’obfuscation VM et HTML. Pour les tests fonctionnels utilisant des agents, de l’automatisation ou des débogueurs, consultez Tests et CI.