javascript-obfuscator 5.8.0: obfuscation options can now come from remote presets

What happened on 2026-09-20

At 20:23 UTC on 2026-09-20, javascript-obfuscator published version 5.8.0 on GitHub. The release notes list two changes. First, the Pro API now supports custom presets. The optionsPreset option can take the alias of a preset saved in the obfuscator.io dashboard, and both obfuscatePro() and the CLI's --pro-api-token flag fetch that preset and merge its options into the active configuration. Second, a CLI fix: when --pro-api-token is set, passing a VM preset name such as vm-default to --options-preset no longer fails locally; the name is sent to the Pro API instead. The release does not mention new transformations. What changed is where the configuration comes from and how it is merged.

What it means for builds and protection boundaries

For teams that use JavaScript obfuscation to raise the reverse-engineering cost of web front ends, Electron apps or hybrid apps, this change matters mostly on the engineering side. Obfuscation options used to live in the repository, so reviewing the code told you which transformations a release went through. With remote presets, part of the effective configuration lives in an external dashboard and is merged at build time, so the repository no longer fully describes the transformation. That raises a few issues. The same commit built at different times may produce different output if someone edits the dashboard preset. The build now depends on a network service and an API token, and the token becomes one more secret to protect. When a production problem appears, you need to know which options were actually in effect. Also remember that obfuscation raises the cost of reading code. It does not turn keys or core rules shipped to the front end into secrets.

Checks you can put in place

First, if you adopt remote presets, record at least the preset alias, the obfuscator version and the build time in build logs or artifact metadata. If the tool or your wrapper script can print the final merged configuration, archive that as well, but never write the token into it. Second, keep the API token in your CI secret store rather than in package.json scripts or the repository. Third, pin the obfuscator version, and after every preset change run the full test suite against the obfuscated output, not just the source. Fourth, prepare an offline fallback and decide in advance whether an unavailable API pauses the release or switches the build to a local configuration kept in the repository.

Your checklist

• Record preset alias, obfuscator version and build time with each build
• Store the Pro API token in CI secrets, never in the repository
• Run the full test suite on obfuscated output after any preset change