revert "Allow instrumentation to be turned on using .ember-cl"#7738
revert "Allow instrumentation to be turned on using .ember-cl"#7738GavinJoyce wants to merge 1 commit intoember-cli:masterfrom
Conversation
| return configOverride; | ||
| } | ||
|
|
||
| if (config === undefined) { |
There was a problem hiding this comment.
Instead of revertting the whole feature, I think we can just remove the caching here. Without this caching, we would effectively have the same behavior as before WRT blueprint testing, and in the normal ember serve case we would only call this method once anyways...
What do you think?
There was a problem hiding this comment.
I'm happy to remove caching, I was being conservative as I'm not familiar with the impact of removing it. I'll prepare a separate PR while we consider
There was a problem hiding this comment.
This function essentially becomes:
function getConfig(override) {
if (override) { return override; }
return generateConfig();
}There was a problem hiding this comment.
Sounds good. FWIW, this caching should only affect the blueprint testing case. In "normal" command line usage, we would only ever call getConfig once anyways...
There was a problem hiding this comment.
It's also called in instrumentationEnabled. I'm not currently familiar with where or how often that's used though
There was a problem hiding this comment.
Thanks for sorting @GavinJoyce 👏
@rwjblue I was under the impression that it would have been called quite frequently in the instrumentation checks but I could be wrong. Is it just called on instrumentation set up?
|
closing in favour of #7739 |
Reverts #7491
This feature resulted in a bunch of blueprint test failures for tests in ember-source, see this discussion.
Reverting this will unblock some MU blueprint work and give us some time to rethink the implementation of this feature.