Promote buildInstrumentation to public API

[hjdivad]

rendered

• [x] collapse hooks to instrumentation(type, { summary, tree })
• [x] update types to [init, command, build, teardown]
• [x] update details re command, teardown
• [x] rebuild tree teardown -> before build instead of after build

[hjdivad]

Need to revise a couple things after feedback from @rwjblue

[stefanpenner]

👍 (but I am biased, as being one of the implementors :P)

[hjdivad]

@stefanpenner nice, now if we can get @rwjblue to 👍 we'll have complete bias coverage.

[hjdivad]

Updated per feedback.

[hjdivad]

@rwjblue @stefanpenner in particular interested in feedback re: API changes tree -> DAG

[hjdivad]

Should we allow enabling a subset of the instrumentation, without enabling others? For example, should it be possible to turn on init instrumentation without enabling the others? I don't feel very strongly either way, so I suppose we should probably just leave it as "all on" or "all off" until we have a need for that functionality?

I agree. Let's leave it all or nothing until someone actually has a need for more fine-grained control.

[hjdivad]

The usage of adjacentIterator seems odd to me. Per the glossary of graph theory terms "adjacent" means:

I think we came to a consensus about this out of band right?

[rwjblue]

Yes, we definitely did. I just needed some help thinking things through.

Basically, adjacent nodes are direct parent/children (I had misinterpreted the use of edge in the snippet above).

[nathanhammond]

After discussion in today's Ember CLI team meeting we're moving this RFC to FCP. Over the following week please provide your last detailed review to make sure that you're on board with the direction of this new API inside of Ember CLI. Barring significant concerns that result in non-superficial changes to this RFC we intend to land it following the next Ember CLI team meeting one week from today.

Thanks everybody for your work thus far! We're excited to have this new API.