Vitest vi.mock hoisting versus Vite plugin pipeline for virtual modules

Integration boundary

Vitest hoists vi.mock calls before imports execute, while Vite's plugin pipeline resolves virtual modules (e.g., .vue, @vitejs/plugin-vue generated entries) during resolveId and load hooks. The documentation states mocks are "fully hoisted" but does not specify whether hoisting occurs before or after Vite's resolve hooks, leaving plugin authors uncertain about mocking virtual modules that never exist on disk.

Constraints

• Tests run with --pool=forks for process isolation (Vitest 2.0+).
• Virtual modules are generated by Vite plugins, not present in the file system.
• vi.resetModules() clears Vitest's internal cache but does not re-run the plugin pipeline.
• Dynamic imports (await import('./Component.vue')) inside tests may race with mock registration if the module was already cached by the worker.

Goal

Determine whether a hoisted vi.mock targeting a virtual module entry point can reliably intercept the plugin's generated output, or whether the plugin's resolveId hook resolves the real virtual module before the mock factory is registered.

Specific questions:

1. Does vi.mock('virtual:my-plugin') hoist early enough to intercept Vite's resolveId for a virtual module?
2. If a test file dynamically imports a mocked virtual module after vi.resetModules(), will the plugin pipeline re-execute or serve a stale transformation?
3. Is there a supported pattern to mock virtual modules that works consistently across --pool=threads and --pool=forks?