Thoughts on deprecating prototype extensions?

[NullVoxPopuli]

Having primarily worked in addons for some time now, I'm surprised that prototype extensions are still default in apps.

https://guides.emberjs.com/v3.22.0/configuring-ember/disabling-prototype-extensions/

right at the top it says:

By default, Ember.js will extend the prototypes of native JavaScript objects in the following ways:

I'd like to have no native prototype touched by any Library / Framework -- it makes me think of the 2012 times, ya know?

What are people's thoughts on a to-be-written RFC to deprecate prototype extensions / making them an "Optional feature"?

[locks]

I looked into the state of these prototype extensions to provide some more context. Keep in mind that this is for the application blueprint, since the addon blueprint has disabled prototype extensions for quite some time. According to the source code, the existing extensions match the documentation, String, Function, and Array.

1. Function

These have been deprecated and can be disabled by default for 4.0

2. String

These also have recently been deprecated (available as of 3.24.0-beta.1). These prototype extensions could be disabled by default for 4.0 if the deprecation is released (enabled) at the correct time.

3. Array

This one is trickier. There is some discussion in the Array functions RFC. As mentioned in a comment in the thread, I believe Ember Data makes use of these APIs (I'm confirming), so as long as that is true and Ember Data is included in the default blueprint, it would be a breaking change to disable the extensions by default.

I think the work then is to advance the deprecation of the Array prototype extensions so they can be removed at a later major version.

[NullVoxPopuli]

I don't understand:

it would be a breaking change to disable the extensions by default

we, in 3.x's default blueprint:

• disabled the the application-template-wrapper
• enabled glimmer template only components
• turned off jquery integration
• and switched to async observers
• changed all the generated blueprints based on a flag in package.json

those were all by behind optional features, and changed as part of an edition.

by "breaking change" do you mean, "would require edition-level efforts to introduce in the 3.x timeline?

[locks]

You basically answered yourself 😁 What flips the default values for the optional features is the presence of the of the ember.edition key in package.json. If you have a pre-Octane app and upgrade the ember-source version alone to 3.15+ and don't touch anything else, your app will continue working as intended.

[kellyselden]

Could we add ember-disable-prototype-extensions to the app blueprint in a minor release of ember-cli? Would that help the effort?

[pzuraq]

At this point, we're pretty close to v4 and I think in v4 we'll be able to make a much better replacement story for arrays, custom enumerables, and removing array extensions. I actually think it would likely be better to wait until we have that rather than have users update to array functions.

We still need to map out the path there, but I think essentially we'll want to deprecate using and observing the [] property in general, and replace it with custom enumerables.

[NullVoxPopuli]

what's in scope for v4 vs v5?

[sandstrom]

@NullVoxPopuli Just guessing here, but with Ember v4 [assuming IE11 support is dropped], we should be able to do native subclassing of arrays, or use the iterator symbol, for example. I'm guessing those two (and probably more things) are in the toolbox for Ember 4.x.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator

[pzuraq]

Right, native iterators + Proxy make it possible to ergonomically replace the entire custom enumerable system in Ember.

[wagenet]

I think we should get this to an RFC.

[sandstrom]

@wagenet Would this sort under a larger 'Deprecate Ember Classic' RFC? (https://github.com/emberjs/rfcs/issues/832)

[wagenet]

@sandstrom it may well!

[wagenet]

I'm going to close this ticket to encourage further planning and discussion around #832. When that happens, we'll be sure to look back at discussion on this issue and incorporate relevant feedback. Thanks again for discussion here. It truly is helpful!