| 00:23 | <guybedford> | kriskowal: in virtualization use cases, I agree a sync import may well be useful, when it is possible to eagerly link everything and know that the graph is available |
| 00:23 | <guybedford> | the hard part is how we draw a distinction between that use case, and shelling out to the host import module dynamically hook which could do arbitrary async work |
| 00:25 | <guybedford> | effectively it's a class of loaders (like Node.js) that know they can do sync imports, but to draw that line also means restricting host hook fallbacks, unless we can solve sync loading generally via something like an await import.defer(module) that runs first, before then doing the import.now(module) |
| 00:25 | <kriskowal> | Or import.source, as it were. |
| 00:26 | <kriskowal> | That’s effectively where we stand. We are falling back to the sync hook only under import.now, and importNowHook may throw but can’t return a promise. |
| 00:27 | <kriskowal> | Under import, you can never reach importNowHook. |
| 00:27 | <guybedford> | the concern of having a dedicated sync hook is similar to the issue Node.js has where you end up defining two hooks for the loader - the sync hook and the async hook |
| 00:28 | <guybedford> | this seems sub-optimal and prone to bugs if users have implementation differences |
| 00:28 | <kriskowal> | That is the case for us too. |
| 00:28 | <kriskowal> | It’s definitely not ideal, but ideal doesn’t seem to be available. |
| 00:28 | <guybedford> | I think it's possible to separate loading into two phases - an async phase that gets everything ready, and a sync phase that does the linking and execution (down to TLA) |
| 00:29 | <guybedford> | that does mean two graph walks, but that's what instantiate + exec is anyway |
| 00:29 | <kriskowal> | Eager to talk more about that. Sadly, the evening beckons. |
| 00:29 | <guybedford> | so a fully sync graph just means you're already in the second phase |
| 00:30 | <guybedford> | yeah we'll have more time to talk about it I'm sure |