Array.prototype.push has extra "prototype" property

[Jack-Works]

Native version:

Core-js version:

This cause the following error in our environment:

[zloirock]

Could you add a reproducible example and specify the envieronment?

core-js polyfills should work everywhere - even in ES3 - and simple function definition (instead of an arrow or a method shorthand) is the only way to define a method. Functions defined via function have a .prototype property - and it can't be completely deleted - we overwrite it to undefined and can't do more.

[zloirock]

If you just walk over built-ins tree and delete anything unexpected (like it looks in your stack trace) - it's strange, since, if you use polyfills or even not, sooner or later will be added (maybe to polyfills, maybe to a new engine version) something non-writable non-configurable that can't be deleted, like in this case.

[Jack-Works]

I'm using ses (https://github.com/endojs/endo/tree/master/packages/ses).

I run core-js first, then freeze all built-ins by lockdown provided by ses. SES maintains a whitelist of built-in intrinsic and removes all non-standard items.

Maybe I need to cc @erights, @kriskowal and @naugtur? I believe they can explain better why this is necessary.

[Jack-Works]

if you use polyfills or even not, sooner or later will be added (maybe to polyfills, maybe to a new engine version) something non-writable non-configurable that can't be deleted

yes, ses maintains a list of intrinsic and update them when they're stage 3 or 4. Usually, new APIs in JavaScript are configurable so removing them is usually OK (Some exceptions are new well-known symbols).

By the way, I also see these things on TypedArrays. I'm wondering what are those new properties? Does removing them cause something in core-js breaks?

[zloirock]

I'm using ses

That's what I assumed.

I think that for the reason specified above, it's better to fix it on the endo side.

Does removing them cause something in core-js breaks?

It will break new %TypedArray% methods. However, I wanted to rewrite this case with another approach in some months.

[Jack-Works]

and simple function definition (instead of an arrow or a method shorthand) is the only way to define a method. Functions defined via function have a .prototype property - and it can't be completely deleted - we overwrite it to undefined and can't do more.

Now I understand, this is interesting. Maybe it is possible to patch Object.getPropertyDescriptors as well like the [native code] hack? ...Or use Proxy when possible? But it does not sound like a good idea.

[Jack-Works]

Oh! When you define the method in object literal, it will not have a "prototype" property and you can still use this! But is that viable for core-js?

[zloirock]

As I wrote, one source code should work everywhere - methods shorthands do not work in ES5, and creation of that via Function constructor or eval will break CSP.

[zloirock]

Maybe it is possible to patch Object.getPropertyDescriptors as well like the [native code] hack?

It's too heavy and will overcomplicate core-js - I don't think that additional dozen of KB on about half of the Internet pages is a good price for this.

[zloirock]

In case it was a method that does not handle this internally, in modern browsers that have native .bind and allow redefinition on functions .name, it's possible to wrap it with .bind - bound functions have not .prototype - but .push is not this case.

[Jack-Works]

I agree. Looks like there isn't anything core-js can do. Thanks for your reply!

[zloirock]

All that I can recommend it's taking this case into account on endo side or excluding es.array.push from your bundle - however, over time, the list of such modules will be changed...

Maybe, in the future, core-js will be transpilable, and, in this case, will be used methods shorthand that will be transpiled to usual functions only if ES5 support will be required - but it will be not soon.