refactor(context): Future-proofed context.html and debug.html for modularity

[twolfson]

In #1984, we will update context.html and debug.html to centralize the majority Karma's and their logic into scripts. In the next Karma release, we are planning on adding customContextFile and customDebugFile. Since any existing custom context files would be incompatible with this centralization, it would be a breaking change.

To avoid the breaking change/another major release, we want to future-proof context.html and debug.html. In this PR:

• Relocated window.opener/window.parent logic for context.html into context.js
• Relocated window.__karma__ definitions in debug.html to context-debug.html
• Updated debug.html's JS to be override on window.__karma__ rather than define it
  • This will give us leverage if we want something like window.__karma__.stringify to be defined without needing to compile a new context-debug.js

Screenshot of debug.html working:

[twolfson]

One thing I'm uncertain of is if we should call window.__karma__.setupContext(window) here or not. We would need to overwrite window.__karma__ to be a noop in context-debug.js but I can't think of a case when we would need it.

[dignifiedquire]

Crazy idea, couldn't we inject the %CLIENT_CONFIG% into the context.js files, and call .setupContext in there. That way we could add it much easier at a later point in time to context-debug.js if we need to.

[twolfson]

We could inject CLIENT_CONFIG inside of the .js files but would need to do it in a linter friendly way. For example:

// In client.js
window.__karma__.config = {PLACEHOLDER: 'FOR_CLIENT_CONFIG'}

// In middleware
data = data.replace('{PLACEHOLDER: \'FOR_CLIENT_CONFIG\'}', configJson);

imo, the current setup is good since it's minimal tax to maintain (e.g. no chance of escaping errors) and there are no major benefits to the other setup

[twolfson]

With respect to running setupContext in context.js, we can't do that since we would need to override it in debug.html before it's called. Otherwise, we would have overridden window.alert, window.onbeforeunload, and more in debug.html which I believe we don't want

[dignifiedquire]

Let's drop the / in the filenames and add it dynamically on the matches to avoid typo issues in the future.

[twolfson]

I'm confused. Do you mean requestUrl.match(/(karma|context|context-debug)\/.js or to always do replacement (effectively an if true)?

[dignifiedquire]

Can you add the notice about the breaking change in the commit please. See http://karma-runner.github.io/0.13/dev/git-commit-msg.html for how to do that

[twolfson]

Technically, it's not a breaking change since the customContextFile edit hasn't been released yet (i.e. it was landed after 0.13.22). But I will oblige and add the notes there

[twolfson]

I took care of the linter errors. I'm still confused about so I left it alone

#2019 (comment)

I snuck in a rename from context-debug.js to debug.js since it felt more consistent with context.html/debug.html

[dignifiedquire]

Alright retriggered CI to make sure those are green, after that I'm going to merge it. Sorry for the delay

[twolfson]

I hit "Update branch" but it looks like those are creating merge commits instead of doing a rebase. I'm going to rebase in a bit.

[twolfson]

Alright, pushed a rebased flavor

[twolfson]

Ugh, I lost the commit body in my rebase x_x

[twolfson]

Aaaand restored:

refactor(context): Future-proofed context.html and debug.html for modularity

BREAKING CHANGE:

Our `context.html` and `debug.html` structures have changed to lean on `context.js` and `debug.js`.
This is in preparation for deeper `context.js` changes in #1984.

As a result, all `customContextFile` and `customDebugFile` options much update their format
to match this new format.

[dignifiedquire]

Thanks, going to close this in favor of the other PR, so I don't get any issues with merge things as #2020 contains these commits as well

[twolfson]

There should be no issues as long as they are landed in order but works for me =P