Modify afterResolve error handling to allow remote fallbacks

[tdawes]

Clear and concise description of the problem

I'd like to be able to create a plugin that allows me to fallback to a deployed set of remote modules if a version is not available locally. I've tried to use the retry-plugin, but this only seems to apply retries for the manifest/entry files (chunks are still loaded from the original domain), and doesn't seem to update the ModuleInfo after finding a working domain.

I've been able to implement a version using beforeRequest, using a HEAD request to test whether a manifest can be found locally, and updating options.remotes if that fails.

However, it seems like this would be better if we could instead handle this via the errorLoadRemote hook, using the afterResolve lifecycle.

Thoughts?

Suggested solution

There a couple of ways of allowing this, but I wanted to open an Issue to discuss them before submitting a PR:

1. Recalculate the ModuleInfo after the afterResolve hook - this will allow modifications to options.remotes to propagate to the ModuleInfo properly, either via afterResolve or errorLoadRemote.
2. Allow errorLoadRemote to modify the ModuleInfo directly

Alternative

No response

Additional context

No response

Validations

• Read the Contributing Guidelines.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[ScriptedAlchemy]

@cursoragent pretty sure we already support this use case. Research the repo and tell user how to do it