perf(hmr): implement soft invalidation

[bluwy]

Description

When a module is invalidated, and its importers are invalidated recursively (to invalidate import with timestamp to retrieve new module), this PR implements a soft invalidation for those importers as they don't need a full load + transform. They only need to update the import timestamps which is done specifically as a fast path now.

However, some importers may still need to be hard invalidated, for example if they call addWatchFile on certain files. In the module graph, the representation for this is that importer would import those certain files, hence to differentiate files that are actually imported in the file, I created staticImportedUrls.

Soft-invalidation is optional, and is only an optimization for static imports in a file.

Additional context

For the record, I was thinking about this idea before I saw Evan's comment 😄

I had "soft invalidation" in my head, but happy to rename it to "partial invalidation" if anyone prefers it. For me, "soft" kinda refers to soft/hard caches and soft/hard deletes.

---

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 PR Title 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.

[ArnaudBarre]

This is actually something I noticed while implementing my "own Vite" 1 and half year ago but completely forgot to backport this idea.

For sourcemap I think this should be fine because the length of query params will be stable after and before.

[bluwy]

Thanks to Arnaud's suggestion to use HARD_INVALIDATED, it made clear of some bugs (that's now fixed):

• If a module was hard-invalidated once before, it'll never soft-invalidate again in the lifetime of the server (Moved invalidation reset higher in handleModuleSoftInvalidation)
• If a module is soft, then hard invalidated in a HMR chain, the second invalidation will propagate its hard invalidation state to its importers too (Updated seen.has check in invalidateModule)
• The updated code doesn't have the right etag (Regenerated it)

[bluwy]

/ecosystem-ci run

[vite-ecosystem-ci]

📝 Ran ecosystem CI on 7fabbb4: Open

suite	result	latest scheduled
analogjs	✅ success	✅ success
astro	✅ success	✅ success
histoire	✅ success	✅ success
ladle	✅ success	✅ success
laravel	❌ failure	❌ failure
marko	❌ failure	❌ failure
nuxt	✅ success	✅ success
nx	❌ failure	❌ failure
previewjs	✅ success	✅ success
qwik	✅ success	✅ success
rakkas	✅ success	✅ success
sveltekit	❌ failure	❌ failure
unocss	✅ success	✅ success
vike	❌ failure	❌ failure
vite-plugin-pwa	❌ failure	❌ failure
vite-plugin-react	✅ success	✅ success
vite-plugin-react-pages	✅ success	✅ success
vite-plugin-react-swc	✅ success	✅ success
vite-plugin-svelte	✅ success	✅ success
vite-plugin-vue	✅ success	✅ success
vite-setup-catalogue	✅ success	✅ success
vitepress	✅ success	✅ success
vitest	❌ failure	❌ failure

[ArnaudBarre]

Not an easy change, but I think the complexity is quite low compare to the big benefit for HMR perf (this would not be visible in benchmarks that update just a file that self-update, but sure will be in real world usages)