import.meta and TC39 process as a whole

Matthew Robb matthewwrobb at
Sat Aug 5 15:55:06 UTC 2017

It all boils down to direct and indirect evaluation and static contextual
information. It can't be an identifier any more than super or this. It
can't be passed because it's a different type of evaluation that happens
relative to static context, in this case the containing module body.

You can pass access to it by closing over it however.

On Aug 5, 2017 11:47 AM, "Naveen Chawla" <naveen.chwl at> wrote:

Yes although it could be implemented like an object & function underneath
even if it's not officially exposed as one.

I think the key question is for interested TC39 members - whether passing
it around must be expressly disallowed or allowed. If allowed, `module` is
the only choice that won't go against the existing advice against
identifiers being keywords (besides being a more suitable name anyway). If
it must be expressly disallowed, `import` would be the compromise choice.

A use-case for passing it somewhere might be to a static helper function
which lives in another module, and which might use the `meta` information,
and which carries out the import whose parameter is based on some logic
that is repeated throughout the app.

Reasons for disallowing this must come from TC39 - till then I'm stumped

On Sat, 5 Aug 2017 at 19:10 T.J. Crowder <tj.crowder at>

> On Sat, Aug 5, 2017 at 2:35 PM, Naveen Chawla <naveen.chwl at>
> wrote:
> >
> > Thanks for the link! That means that `import` is already on the
> borderline of the spec since it wants to be a function and object.
> No, not at all. It's a keyword. `import.meta` doesn't make `import` an
> object, any more than `` makes `new` an object.
> -- T.J. Crowder

es-discuss mailing list
es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list