feat: support import.meta.hot.invalidate

[IanVS]

Description

Self-accepting modules can call this to continue propagating the HMR update to importers. Conditional hot.accept calls do not work unless hot.invalidate is called when the condition fails.

This was pulled out from #10239, with some docs and tests added. But the real credit here goes to @aleclarson.

Additional context

This is needed for propagating HMR updates from files that should not be treated as react fast-refresh boundaries according to the runtime check.

I think this does not change behavior enough to warrant a breaking change label, but it does change the behavior from simply refreshing the page to propagating HMR upwards. But it's possible that some users were using invalidate() because they wanted a full page refresh.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[sapphi-red]

Thanks!

I have some questions to understand this more deeper.

[IanVS]

Not sure what the failing tests are about, maybe they're flaky?

[sapphi-red]

Sorry, I just remembered we have types for HMR events here. Would you add vite:invalidate?

vite/packages/vite/src/types/customEvent.d.ts

Lines 1 to 13 in 81d4d04

	import type {
	ErrorPayload,
	FullReloadPayload,
	PrunePayload,
	UpdatePayload
	} from './hmrPayload'
	export interface CustomEventMap {
	'vite:beforeUpdate': UpdatePayload
	'vite:beforePrune': PrunePayload
	'vite:beforeFullReload': FullReloadPayload
	'vite:error': ErrorPayload
	}

[IanVS]

Sorry, I just remembered we have types for HMR events here. Would you add vite:invalidate?

I started to do that before, but then I need to add a handler to handleMessage, but those seem like messages from the server to the client, whereas the invalidate message is going the other direction, right?

Should I add a type, but then not add it to the union of HMRPayload?

[aleclarson]

Sapphi is talking about this client-side event, I think

[aleclarson]

I wonder if this client event is even worth adding? What's the use case?

[IanVS]

I assume the use case for all of these is to help debug HMR problems and also to confirm they're working as expected in tests.

If I add the type to the HMRPayload union, then I'd need to handle it where I pointed out because of the exhaustive switch statement. I could create a separate type that's not included in that union, but it would be different from the others. But, I guess it is different, so maybe that's fine.

I'm also happy to remove the notifyListeners if that's preferred.

[sapphi-red]

vite/packages/vite/src/node/server/ws.ts

Line 34 in 81d4d04

send<T extends string>(event: T, payload?: InferCustomEventPayload<T>): void

vite/packages/vite/src/node/server/ws.ts

Line 45 in 81d4d04

listener: WebSocketCustomListener<InferCustomEventPayload<T>>

vite/packages/vite/src/types/hot.d.ts

Lines 28 to 32 in 81d4d04

	on<T extends string>(
	event: T,
	cb: (payload: InferCustomEventPayload<T>) => void
	): void
	send<T extends string>(event: T, data?: InferCustomEventPayload<T>): void

vite/packages/vite/src/client/client.ts

Line 253 in 81d4d04

data: InferCustomEventPayload<T>

It seems InferCustomEventPayload is used for both client -> server and server -> client.
So I think addding to CustomEventMap and not adding to HMRPayload makes sense.

[IanVS]

@sapphi-red I'm not sure if I did this correctly, since it seemed like I needed to re-export the type from a lot of files, but at least the build is passing for me locally. The macos failure here looks like flake, I think.

[sapphi-red]

Thanks 💚 LGTM