Communication Channel opened by import.meta

[jridgewell]

Part of the discussion was about a communication channel opened by import.meta. It centers on the cached object being reused in a second evaluation of the module as part of Steps 3 and 4.f.

However, the module that this object is cached on is not reused another evaluation of the module. GetActiveScriptOrModule() grabs the active module from the execution context. I don't believe there can ever be a second evaluation of the same module that would reuse this execution context.

With that, I don't see import.meta being any different than a module-scoped const declaration at the beginning of the module. Something like:

const __SPECIAL_MODULE_SCOPED_IMPORT_META__ = { url: 'https://example.com' };

function foo() {
  // import.meta.url
  __SPECIAL_MODULE_SCOPED_IMPORT_META__.url
}

I don't think there are any communication channels opened by this proposal.

/cc @erights

[ljharb]

I'm also confused why any callsite-based mechanism to produce a mutable object is problematic.

In fact, the current semantics of tagged template literal arrays - being cached per callsite and not per realm - seems to suggest that they don't, in fact, need to be frozen.

Can someone help me understand the hazard here?

[jridgewell]

Before the Tagged Template Literal revision, there was an absolute need to freeze the shared literal. This is because it could be retrieved (with the same identity) from any module at any point:

// a.js
const strings = (s => s)`foo`;
strings.bar = 1;

// b.js
const strings = (s => s)`foo`;
assert.equals(strings.bar, 1)

I don't believe import.meta is exposed in the same way, so it should be fine.

[ljharb]

Agreed, but with that revision, there seems to be no further need - similarly, import.meta has no need.

[MylesBorins]

Closing as proposal is now stage 4