You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having recently implemented the first pass at supporting ESM in the SES shim (to be released next week as 0.8.0), I’m wondering what case motivates the need for importNowHook. The only case I imagine might need such a hook was built-in modules, but I found that the moduleMap constructor argument adequately served that need. The behavior of import seems to be fully fleshed in terms of moduleMap, resolveHook, and importHook.
If there is no surviving motivating case, we may have an opportunity to remove it.
The text was updated successfully, but these errors were encountered:
Renaming importHook to loadHook #26 clarifies its role as a function that drives the module loader but does not result in initialization of any modules (as implied by “import”). Given also that the moduleMap and moduleMapHook afford injecting built-in modules synchronously, I move that we remove importNowHook from the Compartment proposal.
I believe we would need affirmation from our collaborators at Moddable to make such a change. @phoddie@patrick-soquet. Are there objections?
Having recently implemented the first pass at supporting ESM in the SES shim (to be released next week as 0.8.0), I’m wondering what case motivates the need for
importNowHook
. The only case I imagine might need such a hook was built-in modules, but I found that themoduleMap
constructor argument adequately served that need. The behavior ofimport
seems to be fully fleshed in terms ofmoduleMap
,resolveHook
, andimportHook
.If there is no surviving motivating case, we may have an opportunity to remove it.
The text was updated successfully, but these errors were encountered: