Frequently asked questions
Which integration should I choose?
The one matching the bundler you already use, because there are direct plugins for Vite, webpack and Rspack, Rollup, esbuild, Next.js, Parcel, Metro for React Native, and Bun. If your build does not use a bundler, the npm CLI operating on your output directory covers the same ground. The editor extensions are for local inspection rather than for producing release artifacts.
Do the bundler plugins exclude dependencies by default?
Not uniformly, and assuming they do is a common and expensive mistake. Only the Bun and Parcel plugins exclude vendor directories by default. With Vite, webpack, Rollup or the others, dependency code is in scope unless you configure an exclusion, which means longer builds and a much larger surface for an exclusion error to break something. Set the boundary explicitly rather than relying on a default.
Where in the build does the plugin run?
After bundling and before the output is written, which is the correct order because protection expects compiled JavaScript. It also means any step that needs to read your code must run earlier: static analysis, secret scanning and dependency review are all substantially less useful against protected output. Order the pipeline so review happens while the code is still readable.
Will protection break my source maps or error monitoring?
Error monitoring keeps working but the traces arrive with renamed frames, so they need translating. Symbolication does that against the protection report from the exact build that produced them, which makes archiving a report per release a hard requirement rather than good practice. Publishing ordinary source maps for protected code would undo the protection entirely, so the report is the mechanism rather than a public map.
How do I stop the build renaming names my consumers depend on?
Declare them as reserved names. Anything resolved by name from outside the protected build needs covering: exported functions, callbacks a framework invokes by name, property names read from templates, and identifiers another separately built bundle references. The engine cannot infer which names are public, so this list is how the boundary gets stated. Micro-frontend and module-federation setups need particular care, because a shared mapping does not cross a project boundary.
Can the same configuration drive both local builds and CI?
Yes, and it should. Keep the configuration in version control and let both paths read it, so a release artifact does not depend on which machine produced it. Where developers want a faster inner loop, run a reduced option set locally and the full profile in CI, but let CI be the only path that produces something a customer receives.