fix: invalidate inlined proxy scripts on change

[matthewp]

Description

The dev HTML plugin converts inline module scripts into external proxy scripts. This change makes it so that when a proxy script is cached it also invalidates the module within the module graph. Without this if the script ever changes then the module will be stale.

Additional context

None

---

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.

[matthewp]

I don't know why a downstream merge closed this! Reopening.

[patak-dev]

Let's get this one in, it would be great to get a test in the CI for it at one point 🙏🏼

[matthewp]

Let's get this one in, it would be great to get a test in the CI for it at one point 🙏🏼

Would love some advice on this. This change requires:

1. An inline script in HTML.
2. That changes on each request.
3. Where multiple requests actually happen.

Most of the tests in Vite are frontend (SPA) oriented as far as I can tell. Which makes sense given the normal use-cases, but it makes testing server-oriented code more difficult.

One thing that makes Vite difficult to test is that a lot of functionality is inside of the HTTP server, and testing HTTP servers can be quite difficult. If the middleware were abstracted so that they did not depend on a running port it would be easier to test their functionality.

[patak-dev]

@drwpow added two playgrounds: ssr-html and ssr-pug, that are closer to what Astro is doing

To test this, I think that this dynamic script could be changed with a counter when a particular request is issued to the server, and then you could check that HMR was properly triggered here by checking some side effect on the DOM. But I need to dig a bit deeper to see if there are blockers to do this, maybe it is more clear to @drwpow that was already playing with these tests.

[drwpow]

But I need to dig a bit deeper to see if there are blockers to do this, maybe it is more clear to @drwpow that was already playing with these tests.

No blockers that I’m aware of. That sounds like a good test of this invalidation to me.