Failed dynamic import should not always be cached

[haoqunjiang]

Given feedback from https://bugs.chromium.org/p/chromium/issues/detail?id=1195405#c9

In my opinion, HTML spec should also stop demanding to cache failed dynamic imports.

---

The rationale of this proposal is well discussed in tc39/proposal-dynamic-import#80
The ECMAScript spec has adopted the change long ago: tc39/ecma262#1645

---

Lack of retry-ability is stopping SPA developers from using native dynamic imports. Because they would have to reload the whole web app, only to make up for an otherwise insignificant network failure when fetching a lazy-loaded js chunk.

[haoqunjiang]

cc/ @hiroshige-g @domenic

While Safari isn't conforming to the spec in this case, I think their behavior is more intuitive and reasonable to web developers. We should fix the spec, not the browser 🙂

[annevk]

cc @whatwg/modules

[annevk]

If we end up deciding to change behavior here, https://bugzilla.mozilla.org/show_bug.cgi?id=1716019 can be reopened and repurposed.

[hiroshige-g]

Some random thoughts (I'm neutral about whether this change should be made or not; focusing its feasibility here):

Should we retry { fetch errors | parse errors | instantiation errors | evaluation errors }?
I prefer just retrying (at most) fetch errors, due to its complexity (I assume fetch errors < parse errors <<<< instantiation errors << evaluation errors).

Should we retry in {dynamic imports | static imports | <script src>}?
Perhaps all according to tc39/proposal-dynamic-import#80 (comment).

How it should be specified?
Primarily we should change
https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script
to allow retrying fetch when previous result is null (by clearing moduleMap[url] instead of setting it to null in Step 9, or by only early returning when moduleMap[url] exists AND it is not null in Step 3), but we also have to check other uses of module maps especially we want to retry parse errors.
In this way, fetch errors are always not retried within a single import() thanks to visited set around https://html.spec.whatwg.org/multipage/webappapis.html#internal-module-script-graph-fetching-procedure, may be retried between multiple concurrent import()s, and are always retried when starting another import() after previous import() was rejected (if there are no other module fetches).

[leobalter]

Thanks @hiroshige-g!

I believe these are similar thoughts from @domenic's comment (from 2019):

(...) Tentatively we have the following thoughts:

• This should behave the same for static and dynamic imports. For example we should just not cache failed fetches (we currently do). This is important if, for example, you do import("./a") where ./a statically imports ./b and ./b has a transient network error. You will want to just retry import("./a").
• We are unsure how to treat parse errors. Should we continue caching them? Or should we allow retrying failed parses?
• How this impacts multiple parallel module graph fetches seems complicated.

One thing that I'm imagining here:

to allow retrying fetch when previous result is null (by clearing moduleMap[url] instead of setting it to null in Step 9, or by only early returning when moduleMap[url] exists AND it is not null in Step 3)

I believe if Step 3 just says something like: If moduleMap[url] exists and is not null would also require a change in Step 2, as this one would need to loop back if moduleMap[url] goes back to "fetching". Maybe this is

2. If moduleMap[url] is "fetching", wait in parallel until that entry's value changes, then queue a task on the networking task source to proceed with repeating this step.
3. If moduleMap[url] exists and is not null, asynchronously complete this algorithm with moduleMap[url], and return.

The new Step 3 would have an immediate follow up to change a null moduleMap[url] to "fetching".

Step 2 works today because there is no repeated "fetching".

I hope this helps moving this issue forward towards an effective resolution!

[haoqunjiang]

Is there anything I can do to move this issue forward?

[07akioni]

Any progress?

[davidwallacejackson]

I'm guessing this hasn't made much progress because there aren't a lot of people clamoring for a solution, so I'm just here to be an additional squeaky wheel. I'm about to "fix" this in my own project by implementing a service worker that will retry only requests for javascript files, which strikes me as an extremely drastic measure to have to take to guard against a common condition like flaky connectivity.

The user experience when this fails is also really, really bad -- parts of the app just entirely fail to load, and as far as I can tell the only mitigation short of the service worker approach would be to report that an error happened and encourage/force the user to reload the page. It's a bad look for the app developer, and I don't think most engineers know that this is a danger when implementing code-splitting, which is part of all the major SPA frameworks and a standard recommendation for large apps. I'm really surprised I haven't heard about this biting more people, and I wonder if a lot of teams either don't know this is happening to them or have given up on solving it.

[LabEG]

Same problem. I use microfrontends with chunks. I'm trying to protect against chunk loading error when deploying a new microfrontend version. Because the old chunks are gone. I'm trying to reimport a microfrontend, but it's cached.

[AlonMiz]

I was struggling with this issue and found a workaround. and had the chance to even write about it here:
it shows the workaround with react.lazy, but the same mechanism can be applied in any framework or vanilla js.
Retry dynamic imports with “React.lazy”