Avoid __proto__ syntax

[GrosSacASac]

Expected Behavior / Situation

rollup does not use deprecated syntax.

Actual Behavior / Situation

rollup uses the deprecated __proto__ syntax https://www.ecma-international.org/ecma-262/10.0/index.html#sec-additional-ecmascript-features-for-web-browsers

Just saw #3136

Modification Proposal

Replace

var x = Object.freeze({
  __proto__: null,
  bar: bar
});

with

var x = Object.freeze(Object.assign(Object.create(null), {
  bar: bar
}));

or

var x = {
  bar: bar
};
Object.setPrototypeOf(x, null);
Object.freeze(x);

or

var x = Object.freeze(Object.setPrototypeOf({
  bar: bar
}, null));

[mheiber]

What are the trade-offs between the approaches?

• Approach 1 (current): __proto__
• Approach 2: Object.create()
• Approach 3: Object.setPrototypeOf then freeze in a separate line
• Approach 4: Object.setPrototypeOf and freeze in a single line

[GrosSacASac]

Approach 1 is recommended against in the specification.
Approach 2 and 3 might have performance differences.
Approach 3 and 4 is essentially the same, with different coding styles.
I would initially go with approach 3. And optimize later.

Do we want to change this ?

If yes I could submit a PR, otherwise feel free to close the issue.

[lukastaegert]

I cannot find any specific recommendation in the document you linked. As a matter of fact, this document properly defines the semantics of accessing __proto__, the only caveat being that it is an optional feature. However to my knowledge, all commonly used JS runtimes support it. The reasons why it should not be used are the same why Object.setPrototypeOf should not be used–mutating or switching the prototype will deoptimize the runtime. This unfortunately rules out approaches 3 and 4. The advantage of the approach we chose is that the prototype is changed before any optimization took place. We even consulted a Google engineer about possible performance concerns: #3096 (comment)

Also it is very concise syntactically. The Object.assign approach itself has bad performance that depends on the number of copied properties and also does unnecessary shape mutations which are slow themselves.

Thus our approach is the only one I would feel good to have enabled by default, and It has already been discussed with various experts. If there are concerns about the optional nature of the feature, we would be open to a PR that adds an option to deactivate it, similar to output.freeze.