Kod zobfuskowany przez VM zgłasza błąd w czasie wykonania — może to być RangeError: Invalid array length, ale ta sama lista kontrolna dotyczy również innych nieoczekiwanych błędów pojawiających się dopiero po obfuskacji. Poniższe kroki należy wykonać po kolei. Pierwszy z nich wychwytuje zdecydowanie najczęstszą przyczynę, pozostałe pozwalają zawęzić rzeczywisty błąd.

Krok 1 — sprawdzenie środowiska pod kątem opcji target

Najczęstszą przyczyną błędu Invalid array length i podobnych jest rozbieżność między opcją target a środowiskiem, w którym kod faktycznie działa, w połączeniu z vmSelfDefending: true.

Środowiska, w których to następuje:

• Node.js (uruchamianie zobfuskowanej paczki bezpośrednio przez node)
• Headless Chrome / Chromium, PhantomJS
• Puppeteer, Playwright, Cypress, Selenium / ChromeDriver, Nightmare
• jsdom i inne emulacje DOM po stronie serwera
• Dowolne środowisko, w którym natywne wbudowane funkcje przeglądarki zostały podmienione lub obłożone hookami

Jeśli używane środowisko znajduje się na tej liście, błąd oznacza, że zabezpieczenia działają zgodnie z założeniem, a nie że wystąpiła usterka. Należy wybrać rozwiązanie odpowiadające danemu przypadkowi:

• Świadome uruchamianie w Node.js (skrypt po stronie serwera, narzędzie CLI, główny proces Electrona): przy obfuskacji należy ustawić target: 'node'. Warstwa self-defending skalibruje się wtedy pod Node zamiast pod przeglądarkę.
• Uruchamianie testów automatycznych / E2E na zobfuskowanej wersji (Cypress, Playwright, Puppeteer, Selenium): należy przygotować osobną wersję testową z vmSelfDefending: false. Opcja ta z założenia uniemożliwia automatyzację i nie da się jej wyłączyć dla pojedynczych narzędzi. Pełną listę niezgodnych środowisk zawiera strona VM Self Defending.
• Błąd występuje mimo uruchamiania w prawdziwej przeglądarce: należy upewnić się, że żadne rozszerzenie, skrypt narzędzi deweloperskich ani strona opakowująca nie podmienia natywnych funkcji wbudowanych (Array, Function.prototype, JSON itp.). Przed uznaniem tego za usterkę warto odtworzyć problem w czystym profilu.

Krok 2 — zawężenie problemu do pojedynczej funkcji

Jeśli Krok 1 nie rozwiązał sprawy, błąd tkwi w konkretnym fragmencie przekształconego kodu. Należy przełączyć się na vmTargetFunctionsMode: 'comment' i dodawać /* javascript-obfuscator:vm */ do kolejnych funkcji pojedynczo, aż błąd wróci. Funkcja oznaczona w momencie ponownego pojawienia się błędu jest winowajcą — to właśnie ona stanowi minimalny przypadek odtwarzający problem, który należy przesłać do działu wsparcia.

Krok 3 — zgłoszenie błędu

Po wykluczeniu rozbieżności między target a self-defending i zawężeniu problemu do jednej funkcji należy napisać na adres support@obfuscator.io. Im więcej z poniższych informacji trafi do zgłoszenia, tym szybciej uda nam się naprawić usterkę:

• Pełny ślad stosu błędu, dokładnie w takiej postaci, w jakiej pojawia się w konsoli — nie parafraza.
• Opcje obfuskatora w formacie JSON. Należy skopiować cały użyty obiekt opcji (albo nazwę presetu wraz z nadpisaniami). Subtelne interakcje między opcjami zdarzają się często, dlatego potrzebujemy dokładnego zestawu.
• Wersja obfuskatora — widoczna w prawym dolnym rogu edytora.
• Środowisko — przeglądarka wraz z wersją, wersja Node.js, system operacyjny oraz wszystko, co odbiega od normy (rozszerzenia, polyfille, własne funkcje wbudowane).
• Minimalny przypadek odtwarzający problem — najlepiej pojedyncza funkcja z Kroku 2 wraz z miejscem wywołania niezbędnym do wywołania błędu.
• Oryginalny kod źródłowy (sprzed obfuskacji), o ile to możliwe. Zobfuskowany wynik jest nieprzejrzysty również dla nas; bez kodu wejściowego musimy poddawać inżynierii wstecznej własny kod bajtowy.