Restructure Ember.libraries to be more idiomatic. Fixes #9291

[jayphelps]

Requested by @stefanpenner #9291

[jayphelps]

@stefanpenner Looks like this might have been in vain. ember-inspector makes the assumption that Ember.libraries is array-like in tons of places. This PR as-is will break that. So....thoughts?

https://github.com/emberjs/ember-inspector/blob/e7cc751cd5d934c6ac55159c6a94e1c2f7e8be24/dist_common/in-page-script.js#L7
https://github.com/emberjs/ember-inspector/blob/bda7a51b00fb243a4a1a3102dcfd89c1a47bdfa7/ember_debug/general_debug.js#L25

etc.

[jayphelps]

Passing now. Had to account for Ember.warn being stripped in prod builds.

[rwjblue]

@jayphelps - the concern about ember-inspector still needs to be addressed right?

[stefanpenner]

cc @teddyzeenny

[jayphelps]

@rwjblue Yep. Needs to be addressed either in this PR or inspector. Maybe a combination of both during a transitional phase.

One thought..I can mock the array-like behavior, adding deprecation warnings for anyone else who might happen to be depending on that. and provide a more public API that inspector can switch over to. I'd be happy to do the PR work on inspector as well if this sounds acceptable. Otherwise I'm open to suggestions..

[teddyzeenny]

We can easily update the inspector (it should keep supporting the old version though). I'm more worried about Ember.libraries being a public API, and Ember Inspector is just one of many libraries and apps using it. As @jayphelps suggested, mocking the array-like behavior might be a good approach.

[jayphelps]

So basically....I've been banging my head the past couple days trying to actually implement these changes in a way that A. won't break old Ember Inspector's, B. preferably not break third parties using the existing array-like behavior.

I tried mocking the array-like behavior and quickly found existing Ember Inspector doesn't just expect it to have array-like methods, it also expects it to basically be an array. I couldn't find a way to mock the array-like behavior in a way that Array.prototype.slice(Ember.libraries) would still work as expected. (please correct me if someone knows the magic way)

We can't actually extend the Array.prototype and maintain all the array-like behavior either since browser support for this is terrible and not worth it.

SO...now I basically came full circle. I don't think there's anything that can be done about this without breaking old inspectors and third party code that relies on this. I'm stuck, so if anyone has a solution please let me know. Maybe there's some way we can do both the old way with a real array and a new way for a transitional period? That's the only way I know of.

At the very least, we can stop using the libraries.each helper, and deprecated it, which fixes #9339.

[teddyzeenny]

@jayphelps thanks for spending time on this. There are no old versions of the inspector, it's always auto-updated to the latest version everywhere, so no need to worry about inspector issues, we'll just update it and publish.

The only thing to worry about is other libraries. If we can assume that they just use it to register themselves, then just keeping the method libraries.registerCoreLibrary should be enough. Thoughts?

[jayphelps]

@teddyzeenny If we're okay with that, then we're golden. AFAIK Chrome extensions don't apply the auto updates until the browser is restarted though, like Chrome itself? If we're OK with breaking that?

We can add a warning that they're likely using an outdated version of inspector, is there a way to access the inspector version number? I see it's injected into the inspectors container at config:main but I can't seem to find a path I can access it in the browser context.

[wagenet]

@teddyzeenny @stefanpenner is this good to go?
@jayphelps can you squash your commits?

[stefanpenner]

@teddyzeenny r?

[jayphelps]

@wagenet I was hoping to get some feedback from @teddyzeenny. (See my last comment)

This PR is NOT ready, but I'll go ahead and guess what he'll say and go off that.

[teddyzeenny]

@jayphelps let's not worry about the inspector. I'm always working under the assumption that everyone has the latest inspector version.

[rwjblue]

@jayphelps - What is left here? If nothing, then it needs a rebase...

[rwjblue]

Will need a rebase.

[jayphelps]

@rwjblue Rebased and AFAIK ready. On the inspector side, emberjs/ember-inspector#263 is needed.

Cc/ @teddyzeenny

[rwjblue]

Looks good to me. I think we need to merge and release emberjs/ember-inspector#263 before merging this (otherwise inspector blows up for canary apps).

@teddyzeenny - Can you let us know when we are good to merge here?

[teddyzeenny]

New Ember Inspector version released. This can be merged.

[stefanpenner]

👍 you are welcome to merge @teddyzeenny (i know you have commit bit)