Normative: add import.meta

[devsnek]

This is the spec text for the stage 3 proposal import.meta.

Tests are available in both test262 (tc39/test262#1888) and wpt (web-platform-tests/wpt#7888). Implementation status is very good (JavaScriptCore, QuickJS, SpiderMonkey, V8, Moddable XS, engine262, Babel, Rollup, probably more), and it is shipping in many browsers (87% on https://caniuse.com/#search=import.meta).

[ljharb]

Should it be asserted that it is an ordinary object? iow, a proxy wouldn’t be valid here.

[michaelficarra]

I don't love that we're adding two hooks, where one is strictly more powerful than the other. What's the point of the restrictions on the return values of HostGetImportMetaProperties if HostFinalizeImportMeta just gets to do whatever it wants? I'd much prefer that we just create an empty object, pass it to HostFinalizeImportMeta, and let that do what it wants.

On a separate note, I don't think the module record alone as a parameter to one/both of these host hooks is sufficient. I imagine a host may want to make the value of import.meta dependent on how the module was imported (declarative/dynamic), which module(s) imported the module, or additional meta-info as in the module attributes proposal.

[devsnek]

@michaelficarra

I don't love that we're adding two hooks [...] I'd much prefer that we just create an empty object, pass it to HostFinalizeImportMeta, and let that do what it wants.

I'd be fine with that too. One thing to note is that the HTML spec uses HostGetImportMetaProperties.

dependent on how the module was imported (declarative/dynamic)

Those use identical spec machinery, I would argue that should never be visible information (and I'm not sure how it would be exposed anyway, since both can happen to the same module)

which module(s) imported the module

I'm not entirely sure what that entails but a host has access to its own module graph.

additional meta-info as in the module attributes proposal.

Modules have a [[HostDefined]] slot for whatever random stuff the host wants to throw in. I'm not sure how we would plan ahead for any module attributes stuff because that's still a stage 1 proposal.

[michaelficarra]

Those use identical spec machinery

Do they? I'm not great with the module portion of the spec, but HostImportModuleDynamically seems pretty telling.

and I'm not sure how it would be exposed anyway, since both can happen to the same module

Yes, but the module will only be evaluated once.

[...] a host has access to its own module graph

Sure, again thinking along the lines of module attributes, if a module is imported in more than one place with different sets of attribtues, I guess it would have a unique module record, so that should be sufficient for this use case. 👍

Modules have a [[HostDefined]] slot [...]

Ah, the [[HostDefined]] slot perfectly fits the last use case. 👍

[devsnek]

@michaelficarra HostImportModuleDynamically paraphrased is "at some point in the future do your host specific magic and then call FinishDynamicImport" and FinishDynamicImport just the static logic plus fulfilling or rejecting a promise.

Beyond that, your pattern idea here would seem to imply that one might do import x from 'x' and be given something meant only for a dynamic consumer, or import('x') and be given something meant only for a static consumer (and I have zero ideas for what kind of logic/data would need to be switched based on that anyway).

[devsnek]

Also to be clear about the above, part of the "host specific magic" could be setting data in [[HostDefined]] which says whether it was static or dynamic.

[michaelficarra]

Okay I think I'm satisfied that the module record alone should be sufficient for these host hooks. Thanks for the explanations, @devsnek. I still don't think we should be adding two overlapping hooks for this feature, though.

[syg]

We should probably say more about what it can do to the importMeta object that's passed in? It shouldn't, e.g., transmute it into an exotic object by mucking with the internal methods.

[devsnek]

Sounds like that might need to be a more general forbidden extension then?

[syg]

Yeah, the specific case of transmutation into an exotic sounds like a good general forbidden extension to have. Did we discuss the general invariants of this host hook?

[devsnek]

I think as long as this hook doesn't make the object exotic, anything is fair game, including changing [[Prototype]].

[ljharb]

#1892 (comment)

[syg]

I think as long as this hook doesn't make the object exotic, anything is fair game, including changing [[Prototype]].

That seems reasonable. Is this captured in the notes somewhere?

[devsnek]

@syg i couldn't find anything as explicit as my sentence above, but between issues and notes and light discussion with domenic that seems to be the understanding.

[syg]

I still don't think we should be adding two overlapping hooks for this feature, though.

Layering wise there are some advantages in providing both low- and high-expressivity hooks. When reasoning about layered specs, if we know only the low-expressivity hook is implemented by the host spec, that's easier to reason about, right? Since HTML only uses the non-escape hatch, we don't have to really read HTML's implementation of the hook to know import.meta is going to remain a proto-ess ordinary object with only data properties.

Let's chat about this on the next call.

[devsnek]

^ To this point, I'm not aware of any engines (except engine262) which implement both hooks, they just implement the finalize one.

[syg]

^ To this point, I'm not aware of any engines (except engine262) which implement both hooks, they just implement the finalize one.

Yeah, that seems expected. My point was about reasoning about host specs, not so much implementations.

concerns addressed