Diagnosticando erros de execução da VM

Siga estes passos em ordem. Cada um descarta uma causa comum antes que você gaste tempo isolando o código com falha.

1. Descarte as defesas avançadas

Um erro que não faz sentido para o seu código, na maioria das vezes RangeError: Invalid array length, geralmente significa que um build de produção está rodando onde builds de produção não devem rodar. VM Self Defending e VM Debug Protection quebram o código de propósito em executores de testes e outras ferramentas de automação, navegadores headless, Node.js ou jsdom executando um build para navegador e navegadores com o DevTools aberto. Antes de tudo, verifique onde o código que falha está rodando.

Primeiro, descarte as defesas avançadas (VM Self Defending, VM Debug Protection, VM Domain Lock): reproduza a falha com um build de testes que use as sobrescritas de Testes e CI. Se o build de testes funcionar, as defesas estão reagindo às suas ferramentas ou ao seu ambiente, e não quebrando o seu código.

2. Verifique a compatibilidade de execução e isole a função com falha

Verifique se o target, o pipeline de build e quaisquer declarações de ambiente correspondem ao lugar onde o código realmente roda.

Se um build reportar avisos de cobertura como VMNoFunctionsToVirtualize, veja Ofuscação VM para saber o que a proteção VM cobre.

Reduza o caso com falha à menor função e ao menor ponto de chamada que ainda o reproduzam. Use o modo comment para restringir quais funções são virtualizadas.

Se você usa vmBytecodeArrayEncoding com vmBytecodeArrayEncodingKeyGetter, o getter precisa retornar exatamente a chave usada no momento do build. Um getter síncrono exige que a chave esteja definida antes de o código ofuscado rodar. Um getter que retorna uma Promise exige vmAsyncExecutor. Se faltar qualquer um desses requisitos, o bytecode não pode ser decodificado.

Compatibilidade de execução · Externalizando a chave do Bytecode Array Encoding

3. Envie um relatório de bug

Envie um e-mail para support@obfuscator.io. Quanto mais dos itens a seguir você incluir, mais rápido conseguimos corrigir:

• O stack trace completo do erro, exatamente como aparece no console - não uma paráfrase.
• As opções do ofuscador em JSON. Copie o objeto de opções inteiro que você usou (ou o nome da predefinição mais quaisquer sobrescritas). Interações sutis entre opções são comuns, então precisamos do conjunto exato.
• Os avisos do build, se houver: o type, a message e o functionName de cada um.
• A versão do ofuscador - exibida no seletor de versão do painel, abaixo do editor. Para chamadas diretas à API, é o campo version da mensagem result ou chunk_end. Com o pacote javascript-obfuscator, ela aparece na mensagem de progresso (Obfuscating with VM protection (vX.Y.Z)...), que a CLI imprime e que obfuscatePro passa para o callback onProgress.
• O ambiente - navegador e versão, versão do Node.js, sistema operacional e qualquer coisa incomum no ambiente de execução (extensões, polyfills, builtins personalizados).
• Uma reprodução mínima - de preferência a função única da seção 2, mais o ponto de chamada necessário para disparar o erro.
• O código-fonte original (antes da ofuscação), sempre que possível. A saída ofuscada também é opaca para nós; sem a entrada, estaríamos fazendo engenharia reversa do nosso próprio bytecode.

Se o código-fonte for proprietário, diga isso no e-mail - podemos assinar um NDA antes que você o compartilhe. Não conseguimos diagnosticar bugs da VM de forma confiável sem ver o padrão de entrada que produziu o bytecode quebrado, então vale a pena essa troca de mensagens.