Editorial: Provide context for HostImportModuleDynamically requirement #1598
Conversation
I had a hard time figuring out the stability requirement: > Every call to HostImportModuleDynamically with the same > *referencingScriptOrModule* and *specifier* arguments must conform > to the <em>same</em> set of requirements above as previous calls > do. That is, if the host environment takes the success path once for > a given *referencingScriptOrModule*, *specifier* pair, it must > always do so, and the same for the failure path. This adds an editorial note gleaned from discussions on #tc39. If accurate, it may help others.
| @@ -22658,6 +22658,9 @@ <h1>Runtime Semantics: HostImportModuleDynamically ( _referencingScriptOrModule_ | |||
| </li> | |||
| <li> | |||
| Every call to HostImportModuleDynamically with the same _referencingScriptOrModule_ and _specifier_ arguments must conform to the <em>same</em> set of requirements above as previous calls do. That is, if the host environment takes the success path once for a given _referencingScriptOrModule_, _specifier_ pair, it must always do so, and the same for the failure path. | |||
| <emu-note> | |||
| <p>Changes to module caches that are exposed to user code (e.g. `delete require.cache[k]`) must not affect dynamic imports.</p> | |||
There was a problem hiding this comment.
I'm not sure I follow what this is trying to capture? require.cache[k] implies a k being a unique key in a module registry, which is not a concept ECMA-262 deals with at all. Whether a separate registry key change results in changes to dynamic import is not an ECMA-262 concern, rather the ECMA-262 concern is surely already captured that for a given specifier and referencing module, the same resolved module should always be provided. How is this unclear already?
There was a problem hiding this comment.
I agree that we should probably leave require out of it. Perhaps that particular requirement can be stated in a more approachable way (or be merged in with with the previous requirement to which it references).
There was a problem hiding this comment.
This is meant to provide context by referencing widely understood external systems.
I could try to rephrase to refer to something like https://nodejs.org/api/modules.html#modules_require_cache
By deleting a key value from this object, the next require will reload the module.
Adding or replacing entries is also possible.
But that still references something external. Providing context relating to quirks of parallel mechanisms seems hard without external reference.
ljharb
force-pushed
the
master
branch
3 times, most recently
from
3d0c24c to
7a79833
Compare
I had a hard time figuring out the stability requirement:
This adds an editorial note gleaned from discussions on #tc39.
If accurate, it may help others.
@devsnek who explained the context.
@littledan @domenic who probably drafted/championed the requirement.