Keep unreleased features out of your public bundle

Your bundle carries code for features you have not announced, and it reads as a preview of what is coming.

Flag names and route strings read as a changelog

Flag names, route strings and unreleased UI text read like a changelog written for the wrong audience. People diff your bundles between releases and write up what changed. A flag with a readable name gets switched on in devtools and screenshotted before you have said anything publicly.

None of that needs your source. A bundle that ships to every visitor's browser is already there for anyone who wants to look, whether or not you have linked to it.

What a rebuild does to a bundle diff

identifiers.rename renames your identifiers and strings.encode encodes your literals, so there is no newBilling to search for in the shipped file and no unreleased copy to quote. A new seed on every build reshapes the whole artifact, including the code that did not change, so diffing two releases stops being the cheap way to see what is new.

The stronger answer is not an AfterPack setting. Code that has not launched is best kept out of the bundle: a server-decided flag, or a dynamic import behind an entitlement check, means the feature is not in what ships. No preset matches that, because there is nothing left in the artifact to protect.

Protect what stays, remove what does not have to

For code that does stay in the bundle, raise the preset across the build, or mark the module that carries the unreleased feature:

/* @afterpack preset=hard */
export function renderNewBillingFlow() {
  // unreleased UI
}
/* @afterpack end */

Reach for preset medium or hard across the whole bundle first. A directive that raises one module needs Pro. complexity sets the target directly when a preset rung is not the granularity you want.

Confirm the unreleased module is covered

Open the Protection Map, written when protectionMap.enabled is on, and confirm the unreleased module is covered at the target you expect. Keep sourceMap.enabled off on your deploy: a published map hands back your original names and strings whatever preset built the file beside it.

What a client-side flag can still do

Renaming, encoding and a new build shape each release mean the bundle no longer reads as a changelog, and diffing two versions stops being the cheap way in. A flag the client can switch on can still be found and switched on by someone who reads the new build closely. Anything genuinely under embargo belongs behind a server response that decides whether the feature runs at all.

Next

• Presets: the ladder from minify to extreme and each rung's complexity target.
• Directives: what else is worth marking at a higher preset.
• Protection Map: confirming a directive took effect.