Protect Object Declaration

Example

Without this option:

var obj = { name: a[11], value: a[25] };

With this option enabled:

var obj = b(a[32], a[11], a[33], a[25]);

The braces are gone and so is the structure. What remains is a call with four arguments; knowing that arguments alternate key, value, key, value is something a reader has to work out from the helper, and the helper is itself subject to renaming and the other transforms you have enabled.

The generated helper

The engine inserts a small builder into the wrapper scope. In readable form it is:

function _new$obj_() {
  var o = {};
  for (var i = 0; i < arguments.length; i += 2)
    o[arguments[i]] = arguments[i + 1];
  return o;
}

Two consequences follow directly from that shape, and both matter:

• Insertion order is preserved. The loop assigns pairs left to right, so the resulting object enumerates its keys in the same order the literal did. Code that depends on Object.keys ordering or on JSON.stringify field order keeps working.
• The result is a plain object. The helper starts from {} and does ordinary assignment, so the product is an ordinary data object — nothing exotic in the prototype chain, and nothing that behaves differently from what the literal produced.

Configuration

The config alias and the raw engine option are equivalent — set one:

{
  "protectObjectDeclaration": true
}

{
  "options": {
    "ReorderCodeObjectDeclare": true
  }
}

This option works inside the generated wrapper that Code Transposition builds, and enabling it causes that wrapper to be created even for a file that would otherwise not need one. That is expected: the helper has to live somewhere your code can reach it.

Why it helps

Object literals expose intent more clearly than almost anything else in a bundle. A configuration object, a feature-flag map, a role-to-permission table, an API request body — each is self-documenting, and each survives name mangling completely intact, because mangling renames identifiers and these are property keys and data.

Even with Move Members and Encode Strings applied, a literal still shows a reader how many fields an object has and which values are grouped together. Rewriting the declaration path removes that grouping. It is a narrow transform aimed squarely at the most information-dense construct in typical application code.

Shapes to verify in your own build

A flat key/value argument list can represent a straightforward literal exactly. Richer literal syntax cannot be expressed that way, so those forms need to be left as written — and object-heavy code is exactly where you should be running tests against protected output rather than trusting inspection:

• Getters and setters (get x() {}) define accessors, not values.
• Spread ({ ...base, x: 1 }) copies an unknown set of keys at runtime.
• Computed keys ({ [k]: v }) resolve their key at runtime.
• Shorthand methods ({ run() {} }) and __proto__, which has special meaning in a literal but not in an assignment.

Run your suite against the protected bundle, and check anything that reflects over object keys or round-trips objects through JSON. Compatibility validation catches mechanical problems before you execute anything.

Related options

• Move Members hides member access; this option hides object construction. They address opposite ends of the same leak.
• Protect Members renames the keys themselves.
• Code Transposition provides the wrapper scope this option's helper lives in.
• Migrating from the open-source javascript-obfuscator package? Its transformObjectKeys option covers similar ground and is accepted for migration review — see npm migration.