isiahmeadows at gmail.com
Thu Feb 9 13:47:03 UTC 2017
I'm going purely based on memory, but if I recall correctly, the module
name resolution is left entirely to the implementation. That decides
whether two specifiers from two different modules point to the same module.
(Technically, two modules could even share a file path without being in
violation of the spec. Specifiers are unique, but the spec makes no
normative mention of file paths.)
On Thu, Feb 9, 2017, 04:37 Raul-Sebastian Mihăilă <raul.mihaila at gmail.com>
> 1) My understanding is that a module is a singleton. But how does the spec
> enforce that? Section 188.8.131.52 HostResolveImportedModule (
> https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule) says that
> the resolving process of a module must be indempotent. 'Each time it is
> called with a specific referencingModule, specifier pair as arguments it
> must return the same Module Record instance.'
> But in the following scenario:
> import a from 'a.js';
> import b from 'b.js';
> impot c from 'c.js';
> import c from 'c.js';
> export default 3;
> can we be certain that c.js resolves to the same module record and that
> both a.js and b.js print 3? There are two different referencingModule,
> specifier pairs even though the specifier is the same.
> 2) Is it correct that it's mandatory for an implementation to produce
> different module instances in every TopLevelModuleEvaluationJobs? So if we
> have two script tags with type module and with the same script content will
> they always produce different module instances or is it possible for an
> implementation to produce modules without executing a
> TopLevelModuleEvaluationJob and reuse module instances?
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss