fix(types): emitted can return undefined

[lucaswerkmeister]

I’m not sure how strict this project is about undefined types in general, but I found it confusing that the documentation advised to use expect(…).toBeTruthy() on a function (emitted( 'foo' )) that was typed to always return an array (i. e., always truthy).

It might be better to only add the |undefined to the overload with an event name, not to the overload that returns all events at once… not sure.

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

I suppose in theory it’s a breaking change? People who previously assigned the result of .emitted() to a variable with an explicit type might now get a type error. The expected use, inline within expect(), should be fine, though.

Calls like .emitted().foo[0] or .emitted('foo')[0] may also need to be updated, depending on TypeScript config – in the tests, I’ve used the non-null assertion operator.

The PR fulfills these requirements:

• It's submitted to the dev branch.
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
• All tests are passing: https://github.com/vuejs/vue-test-utils/blob/dev/.github/CONTRIBUTING.md#development-setup
• New/updated tests are included

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

[lucaswerkmeister]

After seeing the impact this has on .emitted().foo[0] and .emitted('foo')[0], I’m no longer convinced this is worth it… up to y’all, feel free to close if you want.

[lmiller1990]

Did not review the codebase yet, but I don't think emitted can be undefined - it's an empty object, {}, by default, and emitted().foo is an empty array [] by default, isn't it?

Either way, appreciate the effort to making a contribution. What do you think? I can look more into this if there is an undefined case (if it can be undefined, the types should reflect this).

[lucaswerkmeister]

If emitted().foo was an empty array by default, then it would be a bug to use expect( … ).toBeFalsy() on it, as the documentation advises, because arrays are always truthy, even empty ones. But as far as I can tell, it starts out as undefined.

[lucaswerkmeister]

(emitted() itself can never be undefined, that’s true, but I don’t think this pull request claims that either. emitted(eventName) can be undefined, though.)

[lmiller1990]

Right, I get it now. I think this makes sense. Is this modified test code supposed to be there? I think just having the typings is probably fine. If you can remove that, I'd be happy to merge this.

[lucaswerkmeister]

Without the changes to the test code, I got a CI failure because TypeScript complained about values being possibly undefined, I think.

[lmiller1990]

Ok, I think this makes sense. Thanks!