Unchanged browser chunks are uploaded again across releases when using the Rollup plugin with Vite 8’s default minifier.
The plugin injects PostHog metadata before minification. Vite rewrites that snippet, but the CLI recognises and removes it using exact-text matching. The release ID therefore remains in the source used to calculate the upload content hash.
Environment
- Vite 8.1.5
@posthog/rollup-plugin 1.6.0@posthog/plugin-utils 2.0.0@posthog/cli 0.18.5- Default event release mode and browser minification
Minimal reproduction
Build this module twice with the PostHog plugin enabled, changing only the resolved release UUID:
export const answer: number = 42;
Use content-hashed output filenames and hidden source maps. Our reproduction uses a stub CLI that returns a fixed release UUID and Vite’s write: false, so it requires no credentials or uploads.
Observed output:
Release A: assets/entry-AcrL3YyN.js
Release B: assets/entry-BCFX2saW.js
Chunk ID in both:
b8b34aa8-e1bc-5eea-92e0-adf180935d80
Source-map fields that differ:
file
The plugin’s injected snippet starts with:
!function(){try{var e="undefined"!=typeof windowAfter Vite minifies it, it starts with:
(function(){try{var e=typeof window<`u`?windowVite also changes string quoting and variable names. This no longer matches the template used by find_release_snippet and remove_chunk_id.
There is a second potential obstacle: into_upload hashes the serialised source map, including its changing file field.
Expected behaviour
Changing only the release ID should allow unchanged code and equivalent source maps to reuse the existing upload, while preserving correct stack-trace mappings.
Production evidence
We confirmed the same rewritten snippet in deployed browser assets. One deployment reused 0 of 973 browser maps, while server processing performed after bundling reused 1,847 of 1,856.
The minimal reproduction isolates the snippet mismatch and filename changes; it does not perform an end-to-end upload.
Related reports
- #89837: embedded release IDs change otherwise stable bundle content.
- #4596: Vite 8 removes chunk-ID comments. That fix restores upload discovery, but does not address snippet matching during deduplication.
- #4670: random chunk IDs caused bundle hash changes. Our minimal reproduction retains the same chunk ID.
Unchanged browser chunks are uploaded again across releases when using the Rollup plugin with Vite 8’s default minifier.
The plugin injects PostHog metadata before minification. Vite rewrites that snippet, but the CLI recognises and removes it using exact-text matching. The release ID therefore remains in the source used to calculate the upload content hash.
Environment
@posthog/rollup-plugin1.6.0@posthog/plugin-utils2.0.0@posthog/cli0.18.5Minimal reproduction
Build this module twice with the PostHog plugin enabled, changing only the resolved release UUID:
Use content-hashed output filenames and hidden source maps. Our reproduction uses a stub CLI that returns a fixed release UUID and Vite’s
write: false, so it requires no credentials or uploads.Observed output:
The plugin’s injected snippet starts with:
After Vite minifies it, it starts with:
Vite also changes string quoting and variable names. This no longer matches the template used by
find_release_snippetandremove_chunk_id.There is a second potential obstacle:
into_uploadhashes the serialised source map, including its changingfilefield.Expected behaviour
Changing only the release ID should allow unchanged code and equivalent source maps to reuse the existing upload, while preserving correct stack-trace mappings.
Production evidence
We confirmed the same rewritten snippet in deployed browser assets. One deployment reused 0 of 973 browser maps, while server processing performed after bundling reused 1,847 of 1,856.
The minimal reproduction isolates the snippet mismatch and filename changes; it does not perform an end-to-end upload.
Related reports