Laufzeitkompatibilität

target

• browser - Chrome, Firefox, Safari, Edge.
• browser-no-eval – wie browser, aber die Ausgabe verwendet kein eval(). Nutzen Sie dies, wenn die Zielseite eine Content Security Policy hat, die eval/unsafe-eval verbietet.
• node – Node.js-Umgebung. Browserspezifische Optionen sind deaktiviert (sie benötigen window/document und wären in Node wirkungslos oder würden einen Fehler werfen). Einige vmSelfDefending-Abwehrmechanismen, die auf reine Browser-APIs angewiesen sind – Erkennung von Headless-Browsern, iframe-basierte Wiederherstellung eines sauberen Realms, Anti-Inspector- und DOM-Prüfungen –, werden für dieses Target nicht ausgegeben.
• service-worker – Service-Worker-Kontext. Kein window, kein document, ein anderes globales self.
• userscript – Sandbox eines Userscript-Managers (z. B. Tampermonkey). Die vmSelfDefending-Abwehrmechanismen werden entsprechend angepasst. Erfordert Obfuscator v6.9.0+.
• bytenode – für Code, der mit bytenode zu .jsc kompiliert wird. Erfordert Obfuscator v6.13.0+.

JavaScript

Funktionsnamen und Funktionsquelltext können sich durch Obfuskierung ändern. Verwenden Sie .name oder .toString() nicht als stabile Anwendungsdaten, sondern ausdrückliche Kennungen. Öffentliche globale Namen können abhängig von den Einstellungen sichtbar bleiben.

strictMode

strictMode: null und strictMode: false erkennen ausdrückliche Direktiven, ES-Module und Klassenmethoden weiterhin als strikt. strictMode: true behandelt alle Eingaben als strikt. Stimmen Sie dies auf die endgültige Laufzeit ab; nachträglich vom Bundler eingefügter Strict Mode kann das Verhalten ändern.

CLI / API

Kompilieren Sie TypeScript oder JSX und bündeln Sie die Anwendung vor der abschließenden Obfuskierung. Erhalten Sie Kommentare zur VM-Auswahl bis dahin. Minifizieren, formatieren oder verändern Sie selbstschützende Ausgabe anschließend nicht. Source Maps sind bei VM- und HTML-Obfuskierung nicht verfügbar. Für Funktionstests mit Agenten, Automatisierung oder Debuggern siehe Tests und CI.