As far as I can tell, it doesn't do anything anymore and haven't for a very long time. Yet we kept the code around and registered it into every application for no reason. That being said it seems to be available through Ember.ComponentLookup (as in import Ember from 'ember';) and the fact that it is registered means it can also be looked up. So straight-up removing the code may cause error in the real world, even though the code doesn't do anything useful anymore. (e.g. in ember-test-helper: https://github.com/emberjs/ember-test-helpers/blob/cbbadbe0b44f6d989990375e300422e8a0a50210/addon/src/-internal/build-registry.ts#L103-L105)
Probably should go around addressing any known consumers and then do an intimate deprecation cycle. Alternatively I suppose it could just piggy back on the deprecation for the component layout resolution thing, though they really aren't related (they used to, when overriding this actually worked).
I am talking about this https://github.com/emberjs/ember.js/blob/main/packages/%40ember/-internals/views/lib/component_lookup.ts
As far as I can tell, it doesn't do anything anymore and haven't for a very long time. Yet we kept the code around and registered it into every application for no reason. That being said it seems to be available through
Ember.ComponentLookup
(as inimport Ember from 'ember';
) and the fact that it is registered means it can also be looked up. So straight-up removing the code may cause error in the real world, even though the code doesn't do anything useful anymore. (e.g. in ember-test-helper: https://github.com/emberjs/ember-test-helpers/blob/cbbadbe0b44f6d989990375e300422e8a0a50210/addon/src/-internal/build-registry.ts#L103-L105)Probably should go around addressing any known consumers and then do an intimate deprecation cycle. Alternatively I suppose it could just piggy back on the deprecation for the component layout resolution thing, though they really aren't related (they used to, when overriding this actually worked).