Best Practices for Protecting JavaScript Bundles

Modern JavaScript applications are typically bundled into one or more output files before deployment. This guide explains the best strategy for protecting these bundled applications with ByteHide Shield.

Why Protect Bundles, Not Individual Files

In modern JavaScript development, bundling is the process of combining multiple source files into optimized packages for deployment. There are compelling reasons to apply protection at the bundle level rather than to individual source files:

Technical Advantages

Complete Code Context: Bundlers perform optimizations that may change how your code works. Protecting after bundling ensures Shield has the complete context of your final code.
Optimized Protection: Bundle files already include optimizations like minification and tree-shaking, which complement Shield's protections.
Proper Scope Handling: Bundlers may wrap your code in specific module patterns. Protecting the bundle ensures these patterns remain intact.
Import Resolution: Bundlers resolve all imports and dependencies. Protecting individual files before bundling could interfere with this resolution process.

Practical Benefits

Simplified Workflow: Protecting a few bundle files is simpler than protecting potentially hundreds of individual source files.
Faster Processing: Fewer, larger files are often more efficient to protect than many small files.
Consistent Results: The bundling process itself can be complex. Protecting the output ensures consistent results.

The Correct Protection Flow

The optimal protection strategy follows this sequence:

Source Files → Compilation (TS/JSX) → Bundling/Minification → SHIELD PROTECTION → Deployment

❌ INCORRECT Approach:

Source Files → SHIELD PROTECTION → Bundling → Deployment

This incorrect approach can lead to issues because:

The bundler may not understand protected code
The protection may interfere with bundler optimizations
You would be protecting code that might be eliminated during tree-shaking

Implementation with Different Tools

Automatic Integration with Build Tools

Our build tool integrations handle this automatically, applying protection after the bundling process:

Manual Protection with CLI or API

If you're using our CLI or API directly, ensure you're targeting your bundle output files:

# First, build your project
npm run build  # This typically runs your bundler

# Then, protect the bundle output
shield protect "dist/*.js" --token YOUR_TOKEN

Special Considerations

Code Splitting

Many modern applications use code splitting to create multiple bundle files. In this case, protect all generated bundle files:

shield protect "dist/**/*.js" --token YOUR_TOKEN

Source Maps

If you're generating source maps for your bundles, ensure you configure Shield to handle them correctly:

shield protect "dist/*.js" --source-map --token YOUR_TOKEN

See our Source Maps documentation for detailed configuration options.

Dynamic Imports

For applications using dynamic imports, ensure you're protecting all bundle chunks:

shield protect "dist/static/chunks/*.js" --token YOUR_TOKEN

Example: React Application

For a typical React application using Create React App:

Build the application:
```
npm run build
```

Protect the resulting bundle files:

shield protect "build/static/js/*.js" --token YOUR_TOKEN

Common Questions

Should I protect my development builds?

Generally, protection should be applied to production builds only. Development builds often include additional code for debugging that might interfere with protection or make debugging protected code more difficult.

What about server-side bundles?

For applications using server-side rendering, you should protect both client and server bundles separately. The protection settings might differ between them based on their execution environment.

Will protecting bundles affect performance?

While protection adds some overhead, protecting already bundled and minified code minimizes this impact. See our Performance Considerations guide for optimization strategies.

Conclusion

Always protect your bundled JavaScript output rather than individual source files. This ensures optimal protection effectiveness while maintaining compatibility with modern build processes. Use our build tool integrations where possible for the most seamless experience.