fix: delayed full page reload

[patak-dev]

Description

Should fix #7323, but more testing is needed.
This PR is needed regardless of the bug in the Vaadin Starter.

Continuation from

• feat: non-blocking pre bundling of dependencies #6758
• fix: use relative paths in _metadata.json #7299

Related fixes

• fix: unhandled exception on eager transformRequest #7345
• fix: early discovery of missing deps, fix #7333 #7346

When a rerun has finished and a full-page reload is needed, but we have found new missing dependencies in the process it is better to discard this rerun and delay the reload after a new pre-processing to avoid reloading waterfalls. #6785 tried to do this but the rerun result was still committed (the new esbuild bundled deps written to the cache and the metadata in memory replaced).

After this PR, a rerun is only committed when needed and canceled if the full page reload is delayed. The logic for queueing rerun is also improved.

Note: the general metadata.processing promise is removed since it isn't really needed. If a dependency or dep info is needed, its individual promise should be awaited.

Future work: I think we could simplify the logic of initial optimization / rerun if the initial optimization will be thought of as a scan phase that adds deps to metadata.discovered and a rerun is called afterward. So the scan phase will be more like a speed up way to find missing deps. I think this scan phase could also be done in parallel... it is now blocking the server start, but it could be reworked. This may be important for large apps as the whole user code needs to be traversed by esbuild.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[patak-dev]

Merging as this is a continuation from the work started in #6758, please still review the change and we can do further modifications while we test the beta

[bluwy]

LGTM.

Future work: I think we could simplify the logic of initial optimization / rerun if the initial optimization will be thought of as a scan phase that adds deps to metadata.discovered and a rerun is called afterward. So the scan phase will be more like a speed up way to find missing deps. I think this scan phase could also be done in parallel... it is now blocking the server start, but it could be reworked. This may be important for large apps as the whole user code needs to be traversed by esbuild.

Great idea 👍 Was thinking the same too while reviewing this. I think the code has a lot of moving parts now with things running in parallel. Passing around functions was a bit hard for me to grasp the flow, but it was necessary to control it.