Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Normative: add import.meta #1892

Merged
merged 1 commit into from Apr 2, 2020
Merged

Normative: add import.meta #1892

merged 1 commit into from Apr 2, 2020

Conversation

@devsnek
Copy link
Member

devsnek commented Mar 7, 2020

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).

@devsnek devsnek force-pushed the devsnek:import-meta branch 2 times, most recently from 5d844e2 to 062e652 Mar 7, 2020
spec.html Outdated Show resolved Hide resolved
spec.html Outdated
1. Set _module_.[[ImportMeta]] to _importMeta_.
1. Return _importMeta_.
1. Else,
1. Assert: Type(_importMeta_) is Object.

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 7, 2020

Member

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

@ljharb ljharb mentioned this pull request Mar 7, 2020
11 of 15 tasks complete
@devsnek devsnek force-pushed the devsnek:import-meta branch from 062e652 to 698e98e Mar 7, 2020
@devsnek devsnek marked this pull request as ready for review Mar 12, 2020
@michaelficarra

This comment has been minimized.

Copy link
Member

michaelficarra commented Mar 12, 2020

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

This comment has been minimized.

Copy link
Member Author

devsnek commented Mar 12, 2020

@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

This comment has been minimized.

Copy link
Member

michaelficarra commented Mar 13, 2020

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

This comment has been minimized.

Copy link
Member Author

devsnek commented Mar 13, 2020

@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

This comment has been minimized.

Copy link
Member Author

devsnek commented Mar 13, 2020

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

This comment has been minimized.

Copy link
Member

michaelficarra commented Mar 13, 2020

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.

spec.html Outdated

<p>The implementation of HostFinalizeImportMeta must conform to the following requirements:</p>
<ul>
<li>It must always complete normally (i.e., not return an abrupt completion).</li>

This comment has been minimized.

Copy link
@syg

syg Mar 13, 2020

Contributor

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.

This comment has been minimized.

Copy link
@devsnek

devsnek Mar 13, 2020

Author Member

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

This comment has been minimized.

Copy link
@syg

syg Mar 13, 2020

Contributor

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?

This comment has been minimized.

Copy link
@devsnek

devsnek Mar 13, 2020

Author Member

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

This comment has been minimized.

Copy link
@ljharb

This comment has been minimized.

Copy link
@syg

syg Mar 13, 2020

Contributor

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?

This comment has been minimized.

Copy link
@devsnek

devsnek Mar 13, 2020

Author Member

@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 syg added the editor call label Mar 13, 2020
@syg

This comment has been minimized.

Copy link
Contributor

syg commented Mar 13, 2020

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

This comment has been minimized.

Copy link
Member Author

devsnek commented Mar 13, 2020

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

@syg

This comment has been minimized.

Copy link
Contributor

syg commented Mar 13, 2020

^ 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.

spec.html Outdated Show resolved Hide resolved
spec.html Outdated Show resolved Hide resolved
spec.html Outdated Show resolved Hide resolved
@devsnek devsnek force-pushed the devsnek:import-meta branch from 698e98e to 7062929 Mar 22, 2020
ljharb added a commit to devsnek/ecma262 that referenced this pull request Mar 31, 2020
Co-Authored-By: Domenic Denicola <d@domenic.me>
Co-Authored-By: Sathya <gsathya.ceg@gmail.com>
Co-Authored-By: Peter Robins <github@peterrobins.co.uk>
Co-Authored-By: Gus Caplan <me@gus.host>
@ljharb ljharb force-pushed the devsnek:import-meta branch from 7062929 to 4842ae9 Mar 31, 2020
@ljharb ljharb dismissed jmdyck’s stale review Mar 31, 2020

concerns addressed

@ljharb ljharb requested review from michaelficarra, syg and tc39/ecma262-editors Mar 31, 2020
@ljharb ljharb requested a review from bakkot Mar 31, 2020
@ljharb
ljharb approved these changes Mar 31, 2020
spec.html Show resolved Hide resolved
Co-Authored-By: Domenic Denicola <d@domenic.me>
Co-Authored-By: Sathya <gsathya.ceg@gmail.com>
Co-Authored-By: Peter Robins <github@peterrobins.co.uk>
Co-Authored-By: Gus Caplan <me@gus.host>
@ljharb ljharb force-pushed the devsnek:import-meta branch from 4842ae9 to 3c6dbe6 Apr 1, 2020
@syg
syg approved these changes Apr 1, 2020
@devsnek devsnek added has stage 4 and removed pending stage 4 labels Apr 1, 2020
@bakkot
bakkot approved these changes Apr 2, 2020
spec.html Show resolved Hide resolved
@ljharb ljharb self-assigned this Apr 2, 2020
@ljharb ljharb merged commit 3c6dbe6 into tc39:master Apr 2, 2020
2 of 3 checks passed
2 of 3 checks passed
continuous-integration/travis-ci/push The Travis CI build is in progress
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
netlify/ecma262-snapshots/deploy-preview Deploy preview ready!
Details
@devsnek devsnek deleted the devsnek:import-meta branch Apr 2, 2020
@mysticatea mysticatea mentioned this pull request Apr 2, 2020
4 of 4 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.