Relation to weak import proposal

[guybedford]

@leaverou posted a related proposal in https://lea.verou.me/2020/11/the-case-for-weak-dependencies-in-js/.

It would likely be worthwhile to include a comparison to this proposal.

My own intuition would be that they are very much the same sort of thing - in that the imported bindings are bound to the unexecuted module but the module itself has just not executed yet. The tradeoff to consider between both proposals is then just when and how to do the actual execution given we have this import mode / attribute.

In the context of optional dependencies, the concept comes up that another module in the graph that happens to execute the optional dependency will define it for all the other importers. This then entirely moves the execution timing problem back away from the engine to the user API side which might offer more control - would be very useful to compare these execution models.

[bmeck]

@guybedford this would still perform linkage as it is currently proposed. From what I can tell from that blog post it only checks if a module is already present not that it should try to load the module. So it seems like "weak dependencies" are a detection mechanism based on existing caches and not intended to populate the cache like this proposal intends.

[bmeck]

Forgot to add that "weak dependencies" seem to be more in https://github.com/tc39/proposal-compartments 's importNow hook space.

[guybedford]

Yes something like an importNow function doing the population versus population on binding access sounds like the main difference.