Add the required "default" export mocking caveat to Jest migration guide.

[vilbergs]

Clear and concise description of the problem

It took me a while to realise that I needed to explicitly mock default module exports in vitest. Since this is a rather big change from the way we mock modules in jest, I think it's worth to mention this in the Jest migration guide.

This is well documented in https://vitest.dev/api/#vi-mock, but is easy to miss as it's not a part of the general mocking guide.

Suggested solution

Add a quick note about default export mocking in https://vitest.dev/guide/migration.html#migrating-from-jest. I think this will help people alot.

Alternative

Provide better error messages when people accidentally mock named exports with vi.mock. For example cannot read property 'get' of undefined, did you intend to mock the "default" export? See https://vitest.dev/api/#vi-mock for details.

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[jereklas]

This should be able to be closed as part of this PR? I guess I didn't update any documentation with that fix, do you want an update in either of the documents linked in this issue @sheremet-va ?

[sheremet-va]

This should be able to be closed as part of this PR? I guess I didn't update any documentation with that fix, do you want an update in either of the documents linked in this issue @sheremet-va ?

Sure, let's update documentation.

[sheremet-va]

This should be able to be closed as part of this PR? I guess I didn't update any documentation with that fix, do you want an update in either of the documents linked in this issue @sheremet-va ?

Also, I think I found a potential bug there:

• https://github.com/jereklas/vitest/blob/5183b855f5a72b7a815aba0276af4e857f324e38/packages/vitest/src/runtime/mocker.ts#L125

It's not forbidden to export undefined from a module. Maybe it's better to check in? Or Reflect.has, or Object.hasOwn.

[jereklas]

Or maybe just !target.hasOwnProperty(prop). I wont be able to get to this tonight, but can try putting up a PR fix along with some documentation updates tomorrow. I'll also add a test case for the explicit case where someone sets the export to undefined.

[sheremet-va]

Fixed #1830