Diagnosticar errores de la VM en tiempo de ejecución

Sigue estos pasos en orden. Cada uno descarta una causa habitual antes de que dediques tiempo a acotar el código que falla.

1. Pruebas y CI

Descarta primero las defensas en tiempo de ejecución (VM Self Defending, VM Debug Protection, VM Domain Lock): reproduce el fallo con una build de pruebas que use las sobrescrituras de Pruebas y CI. Si la build de pruebas funciona, son las defensas las que reaccionan ante tus herramientas o tu entorno, no un fallo de tu código.

2. Compatibilidad de ejecución

Comprueba que el target, el pipeline de build y cualquier declaración de entorno coincidan con el lugar donde el código se ejecuta realmente.

La protección VM se aplica a las funciones aptas. En el modo root, vmWrapTopLevelInitializers también puede envolver inicializadores aptos para virtualizarlos; los preajustes de VM actuales lo activan. Revisa las advertencias de cobertura como VMNoFunctionsToVirtualize y usa el modo comment para seleccionar explícitamente las funciones sensibles.

Reduce el caso que falla a la función y el punto de llamada más pequeños que sigan reproduciéndolo. Usa el modo comment para acotar qué funciones se virtualizan.

Si usas vmBytecodeArrayEncoding con vmBytecodeArrayEncodingKeyGetter, el getter debe devolver exactamente la clave usada en la build, y esa clave ya debe estar establecida cuando se ejecute el código ofuscado; de lo contrario, el bytecode no puede decodificarse.

Compatibilidad de ejecución · Clave de Bytecode Array Encoding

3. Envía un informe de error

Escribe a support@obfuscator.io. Cuanto más de lo siguiente incluyas, antes podremos solucionarlo:

• La traza de pila completa del error, exactamente como aparece en la consola, no una paráfrasis.
• Las opciones del ofuscador en JSON. Copia el objeto de opciones completo que usaste (o el nombre del preajuste más las sobrescrituras). Las interacciones sutiles entre opciones son habituales, así que necesitamos el conjunto exacto.
• Las advertencias de la build, si las hay: el type, el message y el functionName de cada una.
• La versión del ofuscador, que se muestra en el selector de versión del panel, debajo del editor. En las builds con la API y con el paquete npm, es el campo version del mensaje result o chunk_end de la API.
• El entorno: navegador y versión, versión de Node.js, sistema operativo y cualquier particularidad del entorno de ejecución (extensiones, polyfills, built-ins personalizados).
• Una reproducción mínima, idealmente la función aislada de la sección 2, más el punto de llamada necesario para provocar el error.
• El código fuente original (antes de la ofuscación), siempre que sea posible. La salida ofuscada también es opaca para nosotros; sin la entrada estaríamos haciendo ingeniería inversa de nuestro propio bytecode.

Si el código fuente es propietario, indícalo en el correo: podemos firmar un NDA antes de que lo compartas. No podemos diagnosticar de forma fiable los errores de la VM sin ver el patrón de entrada que produjo el bytecode defectuoso, así que merece la pena el intercambio.