feat!: enable mocking Temporal without fake timers

[fabon-f]

Description

Resolves #10345

#10654 added support for mocking Temporal with useFakeTimers, but setSystemDate without fake timers still mocked only Date (it's a nice-to-have feature, cf. #10654 (comment)).

This pull request makes setSystemDate mock Temporal.Now if it is available on the global namespace, in addition to Date.

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.
• Please check Allow edits by maintainers to make review process faster. Note that this option is not available for repositories that are owned by Github organizations.

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 vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	08b64a9
🔍 Latest deploy log	https://app.netlify.com/projects/vitest-dev/deploys/6a5296b786bae500087f1864
😎 Deploy Preview	https://deploy-preview-10757--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[hi-ogawa]

I'm not sure we like to bring another own custom "mock date" machinery like packages/vitest/src/integrations/mock/temporal.ts.

I'm wondering if we can drop our mock/date.ts too now and go all in with fake timer. Basically making setSystemDate to be a sugar of something like:

// setSystemDate(date)
// =>
vi.useFakeTimers({
  toFake: ['Date', 'Temporal'],
  now: date
})

Probably we still keep a internal state matrix of _fakingTime x _fakingDate but switch to the above sugar for _fakingTime = false, _fakingDate = truthy scenario.

vitest/packages/vitest/src/integrations/mock/timers.ts

Lines 21 to 28 in ad065a7

	// | _fakingTime | _fakingDate |
	// +-------------+-------------+
	// | false | falsy | initial
	// | false | truthy | vi.setSystemTime called first (for mocking only Date without fake timers)
	// | true | falsy | vi.useFakeTimers called first
	// | true | truthy | unreachable
	private _fakingTime: boolean
	private _fakingDate: Date | null

Such change doesn't look much breaking.

[fabon-f]

I updated the code in line with the suggestion.

[hi-ogawa]

Thanks for follow-up!

Regarding the breaking change aspect of the sugar idea, on the contrary to what I thought, it looks like this is effectively zero breaking change and basically pure refactoring to borrow fake timer Date implementation.

What I was wrongly thinking is that, the change may surface bare vi.setSystemDate would make vi.isFakeTimers = true and thus it may kicks in expect.poll/vi.waitFor/until's fake timer auto advances, but actually we still keep internal states _fakingTime/_fakingDate so isFakeTimers is still false. So, this still hold true:

vi.setsystemtime(0)
await vi.waitFor(() => sleep(100))
console.log(Date.now()) // => 0 (doesn't auto advance still)

[fabon-f]

Note that we no longer need to keep _fakingDate by ourselves because we can get it from this._clock.now. Vitest have to remember just whether fake timers are enabled, only Date and Temporal are mocked, or nothing is mocked.