Start with the simplest policy
For an application that does not need production source maps, explicitly set build.sourcemap to false in the configuration used by CI. The current Vite documentation describes false, true, inline and hidden options. Check your installed version rather than assuming an example applies to every historical build.
If private error diagnostics require maps, choose a separate-map mode and route those files into restricted storage. Avoid inline maps for a private-map policy: excluding .map filenames cannot remove a map embedded directly into a delivered JavaScript file.
Make the release choice visible
Keep the map decision close to the production build configuration, with a short explanation of the diagnostic workflow. A conditional that flips based on an undocumented environment variable is easy to misconfigure in a preview or emergency deployment.
import { defineConfig } from 'vite';
export default defineConfig({
build: { sourcemap: false },
});Inspect what plugins actually produce
A plugin, copied public directory or postbuild step can add files independently of the primary JavaScript compiler. Inventory the completed output after all such steps. Look for source maps, environment files, source archives and debug JSON, including artifacts produced by dependencies.
When using hidden maps, upload them through the approved diagnostic integration and prepare a distinct public directory. CloneGuard staging is intended for loose public assets; it is not a replacement for Vite configuration or a semantic review of bundled business logic.
Test the deployed result
Open the application from the same asset origin that users receive. Confirm lazy-loaded routes, workers and CSS remain available after staging. Request known map filenames without an authenticated diagnostic session and check that private content is unavailable. Repeat after a release rollback.
Record a retained-byte comparison or release receipt for the public tree. This helps investigate accidental deployment changes. It does not conceal the JavaScript that is intentionally shipped, and it does not demonstrate resistance to an AI agent reconstructing the application.
Use a clean-build comparison
A practical regression check starts with an isolated fixture that has one main entry, one lazy import, one stylesheet and a worker if the application uses one. Build with the actual CI configuration and compare the output inventory with the expected artifact types. If a later plugin adds a map or copies a private file, the change becomes visible before publication. Run the fixture with the staged output under the same base path as production, because a release copied to a new directory can appear healthy at the root while nested chunk URLs fail. Keep this compatibility result separate from the source-map exposure result. Recheck the same fixture when upgrading the bundler or changing plugin order.
Practical checklist
- Use the CI-selected Vite configuration.
- Review inline maps and copied public assets.
- Upload private maps before excluding them from hosting.
- Smoke-test lazy chunks, workers and rollback paths.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.