bpstrngr / interface

Ecmascript module interface for clients/imports/functions.
0 stars 1 forks source link

Keep dynamic requires synchronous in module #9

Closed bpstrngr closed 8 months ago

bpstrngr commented 10 months ago

meta/sanitize currently converts dynamic requires to awaited dynamic imports, along with making their corresponding enclosing functions async. This was a tradeoff to support conditional dependency (if(true)require()) instead of all being hoisted as a static import to keep them synchronous.

Synchronous internal or peer dependant calls to the resulting asynchronized functions can be edited to be async as well, but this can get complex beyond simple library initializations, in eg. opaque object hierarchies.

Such peers, relying extensively on commonjs's synchronous loading of what are supposed to be modules, may deserve to be deprecated.

bpstrngr commented 8 months ago

commit 8071336d7e43de234081d9510a390e6c59a8a170 has modified the behavior to always hoist static imports from requires, unless the block in commonjs is already async. This promotes editing internal/peer dependent invocations to be asynchronous along with the corresponding commonjs blocks containing the conditional or circular requires when they need to be kept dynamic. Especially circular requires typically require extensive and necessary edits to be made asynchronous (given eg. a cycle of top-level, static requires - see for example the source definition of rrweb's CSSOM), so an unsupervised general solution is hardly worth it if even possible.

bpstrngr commented 8 months ago

in addition to circular and conditional requires, the case of optional requires has been handled in commit 46841c3de3583ec57ef14751aa8076d8f0f6a6b5. Requires made in try-catch blocks inside the synchronous scope of the module can be treated as dynamic imports along with those embedded in asynchronous functions, due to top-level await capability in modules. The same could potentially be implemented for conditional requires in synchronous scopes.