> On Feb 9, 2017, at 1:37 AM, Raul-Sebastian Mihăilă <[email protected]> > wrote: > > 1) My understanding is that a module is a singleton. But how does the spec > enforce that? Section 15.2.1.17 HostResolveImportedModule > (https://tc39.github.io/ecma262/#sec-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.’
It is up to the host environment to define what constitutes distinct external module resources, how module specifiers are interpreted, and how referencingModule/specifier pairs map to resources. However, underlying intent is that each distinct module resource is loaded and initialized only once. > > But in the following scenario: > > main.js > ```js > import a from 'a.js'; > import b from 'b.js'; > ``` > > a.js > ```js > impot c from 'c.js'; > > console.log(c); > ``` > > b.js > ```js > import c from 'c.js'; > > console.log(c); > ``` > > c.js > ```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. The answer to this must be provided by the host when it publishes its rules for interpreting module specifiers. If the host environment only provided a flat namespace of module resources (or if specifiers of the form “foo.js” all map to a common set of module resources) then the two imports of “c.js” in the example should resolve to the same module record. This is what I would expect from this example, assuming that the host interprets module specifiers in a manner similar to file paths If the initial imports were main.js ```js import a from ‘A/a.js'; import b from ‘B/b.js'; ``` and the imports of c.js were: ```js import c from ‘./c.js’; ``` I would expect that most hosts would interpret the specifiers such that two different “c” modules would be loaded (or an error would occurs if two distinct module resources for “c.js” didn’t exist). > > 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? The expectation is that a host will only enqueue one TopLevelEvaluationJob for each distinct top level module resource. Essentially the host is expected to do the same sort of canonicalization of module specifiers (relative to a ”null” referencing module) that is done by HostResolveImportedModule. Redundant top level references of the same module resource should be ignored. I’m not sure what the proposed HTML spec. says, but I would expect that two module script tags that have a src attribute that resolves to the same resource only do a single load of the module. I would expect each module script tag that lacks a src attribute to be treated as a distinct module resource, even if two such tags contain identical source code
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
