Extensible inspector

[thorsteinsson]

Rendered

I'd like to get feedback before diving deeper into the detailed design.

Big thanks to @rwwagner90 and @acorncom for the help and direction.

[Gaurav0]

I like the idea of using sandboxed iframes for security; my largest concern would have been addons that would use this capability to do the sorts of things only chrome extensions normally could do like getting around the application's content security policy and accessing any 3rd party site.

However, people will chafe under many of the restrictions that sandboxed iframes have, like they do today with Ember Twiddle.

[knownasilya]

Is there any work on an alpha version of this?

I'd like to do a scenario like https://github.com/embermap/ember-cli-tailwind where it adds a /tailwind route to the app in dev mode only. Instead I'd like to have something like that in a custom view in the inspector.

I'm working on a similar addon, but it's for exploring your app only (nothing added to your app) and has a similar layout as ember-cli-tailwind. Located here: https://github.com/knownasilya/ember-addon-viewer

[lukemelia]

This approach seems good from a security and architecture perspective. My initial thought is that extracting ember-data to run in this way could be a good path into this architecture. However, I am struck that not having the ember-data functionality of inspector in production would be a big loss.

Perhaps there could be a hybrid approach where all addons can take the serve devtools package from ember-cli in development, and blessed addons can also publish packages that are consumed by the ember-inspector build process.

Additional thought, what API compatibility issues/constraints does this introduce? Right now, inspector has to worry about backward compatibility with ember apps running at different versions of ember. Inspector would now also have to worry about addon inspector plugins coded to different versions of the addon inspector API.

[RobbieTheWagner]

@lukemelia I agree that attempting to do this with ember-data could be a good testbed for figuring out the path for other addons.

Additional thought, what API compatibility issues/constraints does this introduce? Right now, inspector has to worry about backward compatibility with ember apps running at different versions of ember. Inspector would now also have to worry about addon inspector plugins coded to different versions of the addon inspector API.

Inspector's master branch only supports newer Ember, and uses the new public APIs that @chancancode helped expose for us 🎉. As long as we can get everything in Inspector using public API, I think it should be relatively stable and we wouldn't have to worry about ever changing APIs.

[acorncom]

Inspector would now also have to worry about addon inspector plugins coded to different versions of the addon inspector API.

@rwwagner90 I believe Luke was concerned more with Inspector APIs changing over time and needing to support different approaches there. I wonder if we could explore a capabilities approach akin to managers in Ember and work to be strictly additive in how we increase plugin APIs over time?

[RobbieTheWagner]

@acorncom I think whether we are talking about Inspector consuming APIs or Inspector exposing APIs, we should be safe as long as we make sure we always use public, supported APIs. Then if things had to change from the existing public API, we would have to do a major version bump.

[wagenet]

@thorsteinsson, @rwwagner90, @acorncom is there still interest in moving this forward? If so, I'll make sure that it gets a more proper review.

[webark]

this kind of ties into some of the discussion around #376

[acorncom]

@wagenet I think there's still real benefit to the ecosystem over time to doing something like this. Yehuda was saying something on Twitter recently about separately deployable engines being an important part of Polaris. The RFC here mentions that being a possible way to address the idea, so solving deployable engines might in turn unlock this as well ...