EmberDebug vs Ember Inspector

[teddyzeenny]

What They Are

The repo currently contains two different code bases which are EmberDebug and the Ember Inspector app. Both are completely isolated (even run in different runtime environments in production).

Communication between them goes through adapters that use methods like window.postMessage, and websockets. The relation between them may be similar to the one between an Ember app and its api.

• EmberDebug is more of an extension to Ember core that adds debugging capabilities. This script is injected into the app being debugged when the inspector is started. It is responsible for providing the inspector with all info about the app.
• Ember Inspector is the Ember app that runs in the Chrome devtools panel for example. It is the part that developers see and interact with when using the inspector.

Build Process

EmberDebug and Ember Inspector have separate builds.

• Ember Inspector uses the Ember Cli build process and ends up packaged as a traditional Ember Cli app.
• EmberDebug has a custom build process in Brocfile.js. It ends up as ember_debug.js file in the dist directories.

The only shared build part is the tests which use Ember Cli's test build, though the tests are separated into different directories and no test accesses both.

Downsides of sharing a test environment

• Ember.js Version: Ember Inspector needs to be working on only one Ember version (ideally the latest). EmberDebug needs to work on all Ember 1.x versions. It cannot rely on features > 1.0 though it needs to also support the latest versions.
• Prototype Extensions: Ember Inspector does not need to disable prototype extensions, especially that disabling array extensions (Ember.A) will cause unnecessary overhead. EmberDebug has to work with prototype extensions disabled, and tests should run without them.
• Leaks between their modules and global dependencies for example sometimes causes tests to wrongfully pass.

Possible Solutions

ember-try and ember-disable-prototype-extensions are perfect for EmberDebug but cannot be applied to Ember Inspector.

• Split them into separate repos. The concept may be similar to splitting the API and Ember app into separate repos. This may have further benefits such as people being able to use EmberDebug directly without the inspector - though that needs further discussions (ex: breaking changes). Downside is the overhead of maintaining two repos, the feasibility, and the amount of work needed to extract it (the packaged Ember Inspector that we publish needs to have both).
• Keep them in the same repo but with a better separation story (especially make sure that the tests run in different runtimes).

[rwjblue]

I am not 100% sure exactly how much work maintaining them separately would be, but it seems to be a better long term solution.

@teddyzeenny - Do you have a feel for how difficult development would be separate? Are they completely intertwined, or could we manage them like we do HTMLBars and Ember itself (when we build Ember we include the specific version of HTMLBars we need and all is well)?

[teddyzeenny]

@rwjblue I need to look into it some more. I'll get a better idea once I try splitting them up, but yeah, I think it may be similar to how we include HTMLBars. It's more analogous to having an Ember app and its API in separate repos, but bundling the Ember app into the API code before deployment so the API sever can serve index.html (but the other way round in this case).

Adding any feature most definitely requires working on both repos. Keeping the versions in sync would probably be best.

One complication I can think of is that we have multiple builds (for each browser) with different adapters. We currently build 4 versions of Ember Inspector/Ember debug pairs. I'm thinking we would probably make the EmberDebug repo unaware of this and make it extensible, keeping the multiple dist complexity in Ember inspector alone which would extend EmberDebug with adapter specific code before bundling it (similar to how Ember configures RSVP's async function to use the run loop).

[RobbieTheWagner]

@teddyzeenny @locks @rwjblue do we still think splitting this up is a good idea? I think we could probably do this, and maybe even further splitting if we wanted, as part of making inspector extensible.

[RobbieTheWagner]

Now that we have ember-try running for EmberDebug, I believe the main idea behind the need for this issue is solved. Closing due to lack of response, but if there is desire to split things up still, feel free to reopen.