fix: independently mock each instance's methods for mocked class

[hi-ogawa]

Description

• closes Mocking a module that is a class will have all of its instances to share the same 'mock' #4281

I think the relevant code on jest is around here and it looks like jest is mocking each instance method on construction:
https://github.com/jestjs/jest/blob/2c3d2409879952157433de215ae0eee5188a4384/packages/jest-mock/src/index.ts#L678-L691

I also created https://stackblitz.com/edit/jest-example-z6bfab?file=mocked-class.test.js to compare with jest's behavior.

The approach I took here might not be robust to cover some potential edge cases, but at least for common usages, this fix is a simple one and reasonably makes sense to me.
I was also wondering if such fix/feature could be moved to tinyspy, but I'm not too familiar with the whole concept, so I would like maintainers to review my current approach at this stage to gather opinions.
I left a few TODOs in the code, so I would also appreciate if you have any input for those.
Thanks for the review!

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[netlify]

✅ Deploy Preview for fastidious-cascaron-4ded94 canceled.

Name	Link
🔨 Latest commit	e4bad94
🔍 Latest deploy log	https://app.netlify.com/sites/fastidious-cascaron-4ded94/deploys/656a94390851730008068f37

[sheremet-va]

Is it possible to restore it in jest?

[hi-ogawa]

I checked the behavior on Jest here https://stackblitz.com/edit/jest-example-z6bfab?file=mocked-class-restore.test.js
I might be using mockRestore incorrectly, but Jest doesn't seem to support such use case.
I added a similar test case for Vitest 5b60bbc and mockRestore is currently not working either but in a different way.
Would you wish to align this behavior? (or maybe make it better?)
Personally I think supporting this use case could be done separately as a nice-to-have feature.

---

Actually, I haven't checked what current Vitest's behavior is. I'll compare with that too later.
(EDIT: here it is https://stackblitz.com/edit/vitest-dev-vitest-hao9hx?file=test%2Fmocked-class-restore.test.ts)

[hi-ogawa]

I think I missed one important context #3438 and the rational of this mockRestore override:

vitest/packages/vitest/src/runtime/mocker.ts

Lines 353 to 357 in 736b61c

	mock.mockRestore = () => {
	mock.mockReset()
	mock.mockImplementation(() => undefined)
	return mock
	}

I don't think my current implementation considers global mock restore use case. I think I understand what's the expected behavior, so let me deal with this and I'll add an appropriate test case.

[hi-ogawa]

I update the code so that constructor mocking is preserved after vi.restoreAllMocks, which I think is a desired behavior aligning with #3438.

I made separate test cases mocked-class-restore-explicit.test.ts (to test mockFn.mockRestore) and mocked-class-restore-all.test.ts (to test vi.restoreAllMocks). The "explicit" scenario is still not aligned with Jest's behavior but I feel this use case is unusual and might be difficult to support.
I'd like to know what you think about this scenario. Thanks!