- From: Shu-yu Guo <notifications@github.com>
- Date: Fri, 21 May 2021 09:25:50 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/pull/1444/review/665647344@github.com>
@syg commented on this pull request. > + + : Input + :: |record|, a [=Module Record=] + :: |moduleMap|, a [=/module map=] + :: |base|, a [=/URL=] + :: |seen|, a [=/set=] of [=/URLs=] + : Output + :: a boolean + + 1. If |record| is not a [=Cyclic Module Record=], then: + 1. Return false. + 1. If |record|.\[[Async]] is true, then: + 1. Return true. + 1. [=list/For each=] string |requested| of |record|.\[[RequestedModules]], + 1. Let |url| be the result of [=resolve a module specifier|resolving a module specifier=] given |base| and |requested|. + 1. Assert: |url| is never failure, because [=resolve a module specifier|resolving a module specifier=] must have been previously successful with these same two arguments. I don't grok the module loading stuff enough myself to be confident with any suggested fix. I don't think resolving a module specifier itself can fail, but that a module graph could have failed to Link(). In which case a requested module's url may not map to any module record in the module map. Is there an observable error timing currently for a "SW has a TLA" error vs a linking error? My in-flight [CL](https://chromium-review.googlesource.com/c/chromium/src/+/2903690) in Chrome chooses to only check if a module graph has any TLAs in it if it successfully linked. If it failed to link, it doesn't check if it's async at all and let the linking error propagate. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/pull/1444#discussion_r637051733
Received on Friday, 21 May 2021 16:26:04 UTC