search

tc39 / proposal-defer-import-eval

A proposal for introducing a way to defer evaluate of a module
https://tc39.es/proposal-defer-import-eval
MIT License
208 stars 12 forks source link

No named exports edge case #19

Open guybedford opened 1 year ago

guybedford commented 1 year ago

Was just wondering about the case for a module without any exports, say only imports, where that module represents some ordered execution that should take place.

Currently the deferral would work, but there would be no way to trigger the execution without a named export.

ljharb commented 1 year ago

It seems reasonable to me to disallow defer when no bindings are present?

Jack-Works commented 1 year ago

I don't think it's a problem. The [[Get]] (or [[GetOwnPropertyDescriptor]]) on the ModuleNamespace exotic object can trigger the module execution, so accessing a non-existed property should be able to trigger the execution too.

ljharb commented 1 year ago

@Jack-Works right but in this case there is no module namespace object (for static; and it'd be weird for dynamic for any random .foo to be the encouraged mechanism to evaluate it imo)

nicolo-ribaudo commented 1 year ago

I like @ljharb's proposal. The only reason modules without exports exist is because they have side effects, such as some initial setup of the environment. On the other hand, deferred imports are for "pure" modules, i.e. modules that don't have significant side effects so you can very safely delay their initialization.

If your module only executes side effects, and these side effects are not for the initial setup of the application, it should just export a function that can be later called at any time.