Sharing module's environment (i.e., Module Record) along multiple imports

Allen Wirfs-Brock allen at
Thu May 21 22:24:40 UTC 2015

On May 21, 2015, at 2:48 PM, Park, Daejun wrote:

> [It might be already discussed, but I couldn't find it.]
> According to my understanding, the spec does not specify the behavior of sharing module's environment (more specifically Module Record) along multiple imports, but leaves it as implementation-dependent. If it is true, what is the rationale? Is there any possibility that different browser engines will have different behavior on this?
> For example, suppose that module 'lib' is imported both in module 'a' and module 'b', as follows:
> // lib.js
> var counter = 0;
> export function inc() { console.log(++counter); }
> // a.js
> import { inc } from 'lib'
> export function f() { inc(); }
> // b.js
> import { inc } from 'lib'
> export function g() { inc(); }
> // main.js
> import { f } from 'a'
> import { g } from 'b'
> f(); // 1
> g(); // 1 or 2 ???
> Then, the spec allows both cases:
>  1) a single environment of the module 'lib' is shared for module 'a' and 'b'
>  2) separate environments are used for each module 'a' and 'b'
> In case #1, g() outputs '2', while in case #2, g() outputs '1'.
> In the spec, HostResolveImportedModule(referencingModule, specifier) says that "multiple different referencingModule, specifier pairs may map to the same Module Record instance." So, for the above example, both behaviors are possible. While Node.js implements the case #1, is there any existing (or planned) implementation that implements the case #2?

The intent is that a single module source code resource corresponds to a single Module Record, regardless of the access path that was used to identify the resource. The quoted text from HostResolveImportedModule is saying that it is ok to use more than one "path" to identify a specific resource and you will still get the same Module Record.  Conversely, "./a" referenced from two different places in a directory structure might reference different source code resources and hence yield different Module Records.

Ultimately, it's up to the implementation provided module loader to define the interpretation of all such module references, but a rational expectation for the example you provide is case #1

More information about the es-discuss mailing list