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

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

# Park, Daejun (10 years ago)

[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?

# Allen Wirfs-Brock (10 years ago)

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

# Michiel Sikma (10 years ago)

Indeed, case #2 seems very strange. Fortunately, anyone implementing case #2 will probably soon realize that it breaks the world.