feat(minifier): add property name mangling

[Dunqing]

Oxc can shorten variable names and private class names, but it cannot shorten property names such as obj._field. This change adds optional property mangling. It replaces #23772 and gives bundlers a way to use the same property names across several files.

Feature

• include selects names to mangle. exclude and reserved keep names unchanged.
• The cache can give a property a fixed output name or keep it unchanged.
• The mangler supports member access, object and class keys, destructuring, optional chains, the left side of in, and JSX property names.
• mangle_quoted also handles strings and template literals used directly as property keys. /* @__KEY__ */ and /* #__KEY__ */ can mark one other string or template literal as a property key.
• Short names are assigned in a stable order. More common properties get shorter names. Existing and reserved names are avoided.
• Bundlers can collect names from several programs, create one shared map, and apply it to every program.
• Numeric keys, __proto__, constructor, prototype, TypeScript-only keys, and private names are never changed by this pass.

Design

Property names are part of JavaScript syntax, not local scope. For this reason, the code lives in oxc_minifier. It only reuses the short-name generator from oxc_mangler.

For one program, the order is:

collect names → assign names → rewrite once → compress → mangle variables and private names

Property names are rewritten before compression because compression can remove information about quotes and comments.

For several programs, a bundler collects names from each program, merges the results, assigns one shared map, and rewrites each program once. Collection can run in parallel. All programs must use the same options.

The shared map keeps property names consistent inside one build. The cache has a different job: it keeps fixed names and reservations across separate minify calls.

Example

With include: "^_" and mangle_quoted: true:

obj[`_field`] = 1;
obj._field = 2;

becomes:

obj[`e`] = 1;
obj.e = 2;

Limitation

• Property mangling is unsafe when other code still uses the old property name. Public APIs and names shared with external code, host APIs, imported namespace objects, or separate builds must be excluded or reserved.
• Quote handling is per use. Without mangle_quoted, obj._field may change while obj["_field"] does not.
• The mangler cannot find names built at runtime or stored in arbitrary strings. Code that uses eval, Function, or with must reserve any affected names.
• Compression may create a matching property after this pass has finished. For example, 'f' + 'oo_' may later become foo_ and will not be mangled.
• TypeScript enum reverse mappings are not supported because the transform creates quoted strings.
• Multi-program support is a caller API. The caller must collect every program that shares mangled properties before assigning names.

The public oxc-minify API is stacked in #24741. The downstream multi-chunk integration is shown in rolldown/rolldown#10374.

Supersedes #23772.

AI assistance: OpenAI Codex and Claude were used for research, implementation, review, and testing. The contributor is responsible for reviewing and understanding the changes before submission.

[codspeed-hq]

Merging this PR will not alter performance

✅ 67 untouched benchmarks
🆕 5 new benchmarks
⏩ 9 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
🆕	Simulation	property_mangler[App.tsx]	N/A	8.2 ms	N/A
🆕	Simulation	property_mangler[react.development.js]	N/A	1.4 ms	N/A
🆕	Simulation	property_mangler[binder.ts]	N/A	1.9 ms	N/A
🆕	Simulation	property_mangler[kitchen-sink.tsx]	N/A	18.4 ms	N/A
🆕	Simulation	property_mangler[RadixUIAdoptionSection.jsx]	N/A	177.1 µs	N/A

---

_{Comparing codex/mangle-props-core (5f08776) with main (63ff8ef)}

Footnotes

1. 9 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[Dunqing]

I think this PR is ready to review; this new implementation resolved all reviews of prior attempted in #23772.

[Boshen]

Did you verify against test262 runtime tests?

[Boshen]

PR description, comments, and documentation require work to enable maintainers to understand how this feature works.

[Boshen]

Should we enable this in cargo minsize?

[sapphi-red]

Would you add the reason why this lives in oxc_minifier rather than oxc_mangler to the PR description?

[Dunqing]

Added this rationale to the PR description. Property mangling must inspect and rewrite property-bearing AST syntax before compression erases quote and key context. oxc_mangler is the scope-aware identifier mangler and supplies symbol/private-member names to codegen, so this AST-rewrite phase belongs in oxc_minifier.

[Dunqing]

Enabled property mangling in both test262 runtime and minsize and all look good.

[sapphi-red]

Does the transformer keep /* #__KEY__ */? If not, I guess that would be needed.

[Dunqing]

Does the transformer keep /* #__KEY__ */? If not, I guess that would be needed.

Good catch. The transformer won't touch comments, but currently, codegen will miss printing comments in some places, especially for some inline comments. I will check and fill the gap after the merge.

[Dunqing]

Merging it, the comments issue was worked on #25766

[Dunqing]

Merge activity

• Aug 17, 7:49 AM UTC: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Aug 17, 7:49 AM UTC: Dunqing added this pull request to the Graphite merge queue.
• Aug 17, 7:55 AM UTC: Merged by the Graphite merge queue.

[spaceemotion]

I wonder... is there a way to have the minifier auto-mangle properties in classes that are never exposed outside a module? e.g.:

// reader.ts

class FooReader {
  read(text: string) {}
}

// The only method that gets exported from the module, the class is never exposed
export const readThing = (text: string) => {
  return new FooReader().read(text);
}

Having to configure properly mangling rules kind of feels like I now need to know the inner workings of library/package code instead of the bundler knowing that something can be mangled already 🤔