Build Integration

Add protection after bundling, before deployment.

Keep your existing Vite, Webpack, Rollup, npm, or CI workflow. JavaScript Obfuscator works best as a post-build release step that takes generated JavaScript and writes protected output.

Release Pattern

One protected artifact path for every release.

Use the desktop app to configure and test settings, generate a command, and run the same protection profile from your release script.

Configure onceSave project settings in the desktop workflow.
Automate laterUse the generated command from CI or a release script.
Test protected outputRun smoke tests against the protected build before deploy.
Pipeline

A practical post-build integration flow

The main job is to protect final JavaScript assets while keeping framework builds deterministic. This makes rollback, testing, and release review easier.

1

Build

Let your existing frontend build produce normal JavaScript, CSS, and static assets.

2

Protect

Run JavaScript Obfuscator against the generated JavaScript files or mixed files handled by the desktop app.

3

Validate

Run smoke tests, key browser paths, and any public API checks against the protected output.

4

Deploy

Publish the protected output directory, keeping unprotected source and build artifacts private.

package.json release script shape
{
  "scripts": {
    "build": "vite build",
    "protect": "jso-protector --config jso.config.json",
    "release": "npm run build && npm run protect && npm run smoke"
  }
}
CI job shape
steps:
  - install dependencies
  - run unit tests
  - build JavaScript bundles
  - run JavaScript Obfuscator project
  - test protected output
  - deploy protected artifacts
Framework Coverage

Use one release pattern across modern JavaScript stacks

The key is not forcing every framework into a custom obfuscation model. Compile first, then protect the emitted JavaScript with the workflow that fits the project.

Vite, Webpack, Rollup, esbuild

Protect generated chunks after bundling. Keep bundlers responsible for code splitting, tree-shaking, and source-map generation before the protection step runs.

React, Vue, Angular, TypeScript

Protect the JavaScript they emit, not raw framework source. Preserve public names used by hydration, customer embeds, analytics hooks, or server-rendered templates.

Desktop and mixed-file projects

Use the desktop workflow when a release contains HTML, ASPX, JSP, PHP, or embedded script blocks that need local review before deployment.

Against npm-first tools

How this workflow competes with javascript-obfuscator

The npm package is strongest when a developer wants to own every option inside a Node build. JavaScript Obfuscator should be positioned as the managed workflow: configure visually, protect mixed files, run batches, then automate the saved project.

GUI first

Use the desktop app to create and validate the protection profile without asking every user to edit JSON by hand.

Preset for reviews

Use online JSON presets to share option choices before a profile moves into a desktop project or release script.

npm native

Use the lightweight CLI wrapper when the release is already owned by npm scripts, Vite, Webpack, Rollup, or CI.

Compatibility

Make protected releases testable and supportable

Competitors often surface source maps, exclusions, and browser validation directly in their docs. This workflow now does the same: protect a separate output folder, preserve public names deliberately, and test the protected build as its own release candidate.

Preserve names on purpose

Keep external callbacks, SDK methods, widget entry points, and other public symbols stable with exclusions and reserved-name rules.

Keep source maps private

Review source-map policy, stack traces, and error monitoring before shipping. Protected release artifacts should not accidentally reveal the original source.

Gate releases in CI

Run release-check, protected-build smoke tests, and browser coverage checks before deployment so compatibility regressions fail early.

Why This Closes A Gap

Competitors often lead with npm, Webpack, or enterprise build language. This page makes our workflow explicit.

The desktop app and command-line workflow are real strengths. The site now explains how to use them in modern releases instead of hiding that story inside documentation.

  • Use existing build tools for compilation and bundling.
  • Use JavaScript Obfuscator for protection after build output exists.
  • Use exclusions and cross-file controls to protect bundles safely.
  • Use tests against the protected artifact, not only source output.