Here's a slight variation (branched from this PR) which would lend itself a bit better to nested modules (#543) as it starts to hint at using a context stack:
    leobalter:647-hooks-order...JamesMGreene:pr_650

Thoughts?

I'm hoping to take on #543 next, so this would be important to me.

LGTM, obviously. 👍

@jzaefferer: it's good to have another review as the code was written by me and @JamesMGreene

At least, it does look good to land.

I'm starting to doubt that this feature was a good idea, considering the complexity we're introducing here, along with the concern's @Krinkle brought up on IRC:

What's the use case for having a global one? What is all this beyond renaming setup/teardown to before/afterEach
For the use case of a module teardown/setup I think both are equally a good name.
[...] Alternatively could be done by providing a custom QUnit.module that does that
[...] there is a principle difference with a custom module however. And I believe this will affect (negatively) how it ends up being used.

As an example of a proxied module, here's the one Ember uses. I still don't think this is a pattern we should promote. But maybe there's something better then this and the new QUnit.config methods?

PS: @JamesMGreene can you work on assert.async() next? You can base that on top of your promise branch, if necessary.

Well, we're still in time to drop this feature as 1.16.0 wasn't released yet.

@jzaefferer: I already have async-done basically ready to go... was just waiting to merge the Promise work in first before creating a PR.

I think this feature will makes sense, and I honestly don't see it as complicating things all that much... just an initial speed bump, already resolved in this PR.

Yes, consumers could duck-punch/proxy QUnit.module (like Ember) or use a lifecycle factory (like Wikimedia) but I don't see why that should prevent us from providing a useful feature that potentially eliminates the need for both.

That said, I need us to go one way or the other before I can finish the Promises PR #634 without having test failures and wrap up my async-done branch (for Issue #534) to make it PR ready. So... it would be nice to decide today. 😧

If we axe it now, I will try to work it back into the prototype of the nested modules (for Issue #543), as that combination makes even more sense to me than have a globally configured version.

This is a fix for the current code on master branch. IMHO, we can merge this and keep the discussion before releasing 1.16, but at least we allow @JamesMGreene to continue on #634.

As James said, I also like this feature and yet it can be improved, not 100% removed. Also we will meet on the next week to make a final decision.

Alright, let's keep it at least temporarily and get this fix merged so that I can keep chugging along on the other async-related tasks. We can discuss keeping/killing it for the next release at the conference next week as @leobalter suggested.

For now, I am going to merge this without the reverting commit.

Let's close this one, I'll keep my branch with this unmerged commit.

Merged without revert via squashed commit 76ff48c.