[Boost] Minify JS produces truncated concatenated bundle → "Unexpected end of input" → entire bundle silently fails to execute

[LordLuktor]

What happens

With the Boost Minify JS module enabled (jetpack_boost_status_minify-js = 1), some of the concatenated /_jb_static/??<hash> bundles Boost generates are truncated mid-file. The served content ends abruptly inside a string literal, leaving unbalanced braces. Because a <script> tag treats any parse error as fatal to the entire bundle, every file concatenated into that bundle silently fails to execute — not just the file that's clipped.

Concrete example

Production page on one of my sites, stable repro (same bundle hash across requests):

• Bundle URL: https://herrintrophy.com/_jb_static/??83544c5457
• Content-Length: 29783 bytes (the server isn't cutting the transfer — the cached content itself is truncated)
• Bracket count: 346 { vs 341 } → five opening braces never closed
• cache-control: max-age=31536000, x-ac: 31.mdw _atomic_dca HIT

Last ~200 chars of the served bundle:

function B(e,t,n){if(i){const r=new Error(\`each_key_duplicate\n${n?\`Keyed each block has duplicate key \\\`${n}\\\` at indexes ${e} and ${t}\`:\`Keyed each block has duplicate key at indexes ${e} and ${t}\`}\nhttps:;

Note the trailing https:; — the Svelte error URL string https://svelte.dev/e/each_key_duplicate is cut off mid-template-literal (after https:), then followed by a stray ; and then EOF. Browsers throw SyntaxError: Unexpected end of input when parsing this.

Browser reproduction

fetch('/_jb_static/??83544c5457', { cache: 'no-store' })
  .then(r => r.text())
  .then(code => {
    try { new Function(code); console.log('parse ok', code.length); }
    catch (e) { console.error('SYNTAX ERROR:', e.message, 'size:', code.length); }
  });
// → SYNTAX ERROR: Unexpected end of input size: 29783

Blast radius

Because the bundle fails to parse, every script in it — including scripts belonging to completely unrelated plugins that happen to land in the same concat bundle — silently doesn't run. No console warning, no PHP error, nothing in debug.log. The only visible symptom is that some frontend behaviors silently don't work. It took me several hours to track this down because the bundle returns HTTP 200 and the content looks nearly complete to a casual inspection.

In our specific case, three distinct sources ended up concatenated into the same bundle:

1. Our plugin's htpc-google-fonts.js (a fonts registry + IIFE font loader helper)
2. Our plugin's htpc-frontend-customizer.js (main customizer IIFE with an init() function)
3. Svelte runtime code from another active plugin on the site (the each_key_duplicate error helper is Svelte's dev-mode runtime — it's included via one of the WooCommerce blocks assets, I think)

The truncation happens inside the Svelte piece. Our IIFEs sit before the Svelte code in the bundle but still never execute, because JS script parsing is all-or-nothing.

We suspect the minifier or concatenator has a boundary/size/escape bug when a later file contains nested template literals with embedded expressions (`...${...}... `), or when some total-character-count crosses a buffer boundary. We didn't narrow it further since we're not familiar with Boost's minifier internals.

Workaround we're using

wp option update jetpack_boost_status_minify-js 0
yes | wp edge-cache purge --domain

Setting jetpack_boost_status_minify-js = 0 disables the concatenation entirely. Individual scripts load separately, they all parse and run correctly, and the site works as expected. Other Boost modules (Critical CSS, Cloud CSS, Image CDN, CSS Minify) remain enabled with no issues — only JS Minify had to be turned off.

What would help

1. Confirmation of whether this is a known bug, or a tracking issue if not
2. Ideally, a filter to exclude specific script handles from the Minify JS concatenation so we can re-enable the module globally and only exclude the problem scripts (we couldn't find one in the Boost source that's documented for this purpose — there's jetpack_boost_concat_excludes and related internals but they weren't obviously supported for end-user exclusion)
3. If it's a minifier-level bug, a fix for the underlying truncation

Environment

• Jetpack Boost version: 4.5.8 (also happens with whatever was current on 2026-04-08)
• Two WordPress sites, both showing the same bug: herrintrophy.com and steinmetzprinting.com
• Both on Pressable hosting (Automattic CDN / a8c-cdn in front of nginx)
• Both are WooCommerce stores with ~50+ active plugins
• Both running WordPress 6.8.x (current at time of filing)
• Boost modules active at time of bug: critical-css, cloud-css, image-cdn, image-cdn-liar, image-cdn-quality, minify-js (the broken one), minify-css, minify-common, render-blocking-js

Happy to provide the full bundle content, a HAR file, the complete list of enqueued scripts on the affected page, or any other info that would help narrow it down.