Intent to Prototype and Ship: Import Assertions

523 views
Skip to first unread message

Daniel Clark

unread,
Sep 28, 2020, 7:55:00 PM9/28/20
to blin...@chromium.org

Contact emails
dan...@microsoft.com

Explainer
https://github.com/tc39/proposal-import-assertions

Specification
https://tc39.es/proposal-import-assertions/

Summary
Import Assertions are an inline syntax for module import statements to pass on more information alongside the module specifier. The syntax is as follows (shown here is the proposed method for importing a JSON module):

import json from "./foo.json" assert { type: "json" };

Blink component
Blink>HTML>Script

TAG review
w3ctag/design-reviews#535

TAG review status
Issues Addressed

Risks

Interoperability and Compatibility
Given positive signals from other browser implementers we expect this feature to have wide support across browser platforms.

Gecko: Positive (mozilla/standards-positions#373) Worth prototyping

WebKit: Positive

Web developers: Positive

Ergonomics
This feature will be used in tandem with new module types (JSON, CSS, HTML...), and may have additional future uses with module imports. Performance costs will be pay-for-play.

Activation
Build tools and polyfills may be useful for adoption as import attributes and new module types roll out across various browser platform implementations.

Security
This feature is intended to address the security concern described in w3c/webcomponents#839. Aside from that, the feature does not have any particular security concerns. See the TAG security and privacy review (https://github.com/tc39/proposal-import-assertions/blob/master/tag-security-and-privacy.md)

Goals for experimentation
Validate this feature as a prerequisite for JSON and CSS Modules.

Ongoing technical constraints
None

Debuggability
No special debuggability support needed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests?
No

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1132413

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5765269513306112

Additional Note
If there are no objections we’d like to ship the import assertions syntax in V8 without gating it behind a flag.  The Import Assertions proposal is unlikely to have major changes at this point, and there’s little risk of users taking dependencies on this syntax until features that actually use it (e.g. new module types) are released in a non-experimental manner.  The JSON and CSS modules prototypes are still behind an experimental flag, and any plan to support them by default would be announced separately.

Domenic Denicola

unread,
Sep 30, 2020, 1:25:31 PM9/30/20
to Daniel Clark, blink-dev, s...@chromium.org
Adding back blink-dev; my bad for not replying-all.

Shu (cc'ed) pointed me to how previous features like top-level await have managed to tie together V8 and Blink flags. You add the V8 flag first, then do something like https://chromium.googlesource.com/chromium/src.git/+/a19d7fc6b8427d89ade3e1db19098d065a35f8b6 on the Blink side. The key seems to be SetV8FlagIfFeature. I hope that helps?

-Domenic

-----Original Message-----
From: Daniel Clark <dan...@microsoft.com>
Sent: Tuesday, September 29, 2020 18:07
To: Domenic Denicola <d...@domenic.me>
Subject: RE: Intent to Prototype and Ship: Import Assertions

That's a fair point. I was thinking that the compat risk is minimal if unknown assertions are rejected by default, but I guess that's not even settled per recent discussion at https://github.com/whatwg/html/issues/5640. To some extent I guess this depends on how those discussions and the HTML integration unfold.

One difficulty with launching the assertions syntax behind a flag is that there's a question of how best to coordinate with the existing two experimental flags for JSON and CSS modules. Ideally, turning on JSON or CSS modules would also turn on the V8 flag, but it doesn't look like there's much functionality for coordinating V8 runtime flags with Blink flags. The runtime_enabled_features.json5 are exposed in content_shell under internals.runtimeFlags, but I don't see any existing code where the V8 implementation consumes these in C++.

But I understand that flag management difficulties are not justification for shipping a feature, so worst case scenario we can have 3 flags, and the CSS and JSON modules ones will just not do anything interesting unless the V8 import assertions flag is turned on as well (or else all imports of the module types will fail at runtime, since there will be no way to provide the type assertions). We might then run into difficulties if/when we try to ship an origin trial, but that bridge can be crossed when we reach it.

-----Original Message-----
From: Domenic Denicola <d...@domenic.me>
Sent: Tuesday, September 29, 2020 8:32 AM
To: Daniel Clark <dan...@microsoft.com>
Subject: RE: Intent to Prototype and Ship: Import Assertions

I’m a little wary of unflagging these in V8 if they don't add any actual value for web developers. It would make more sense to me to leave them behind a flag, until such a time as they can ship in tandem with JSON modules or some similar web-developer-facing feature. Otherwise, I wouldn't be confident that all design and implementation issues are sufficiently worked out.

Stated in terms of https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromium.org%2Fblink%2Fguidelines%2Fweb-platform-changes-guidelines&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&amp;sdata=SJB8HRGsknHxOT7GtdKUUDnPsYcb2DDft1EYlRnriIM%3D&amp;reserved=0, I am slightly worried about compat risk if using these to build a web-developer-facing feature uncovers the need for backward-incompatible changes. (E.g., on the HTML Standard pull request for these, there is still debate between Igalia and the HTML Standard editors on changes that are, potentially, compat-breaking.) And I can't see how import assertions, by themselves, move the web forward enough to justify the risk.

From: 'Daniel Clark' via blink-dev <blin...@chromium.org>
Sent: Monday, September 28, 2020 19:55
To: blin...@chromium.org
Subject: [blink-dev] Intent to Prototype and Ship: Import Assertions

Contact emails
mailto:dan...@microsoft.com
Explainer
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fproposal-import-assertions&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&amp;sdata=Ff2tWlJxOo6B5FaeU26%2BjDxNApJCQUYz9RD%2F8CW4RtM%3D&amp;reserved=0
Specification
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftc39.es%2Fproposal-import-assertions%2F&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&amp;sdata=RQMQ7eSa%2FkmTmyZUp28402REmDACC3vzJ8tFkNyzktA%3D&amp;reserved=0
Summary
Import Assertions are an inline syntax for module import statements to pass on more information alongside the module specifier. The syntax is as follows (shown here is the proposed method for importing a JSON module):
import json from "./foo.json" assert { type: "json" }; Blink component
Blink>HTML>Script
TAG review
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F535&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&amp;sdata=ePcAhqVDz8gC8us1jrnCAUzuDzpJTdB%2BaxROVHU1DLk%3D&amp;reserved=0
TAG review status
Issues Addressed
Risks
Interoperability and Compatibility
Given positive signals from other browser implementers we expect this feature to have wide support across browser platforms.
Gecko: Positive (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F373&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&amp;sdata=derpONMWWSCFh7JVhgjbweSJ4JyQfINLmQ45SRAfX5M%3D&amp;reserved=0) Worth prototyping
WebKit: Positive
Web developers: Positive
Ergonomics
This feature will be used in tandem with new module types (JSON, CSS, HTML...), and may have additional future uses with module imports. Performance costs will be pay-for-play.
Activation
Build tools and polyfills may be useful for adoption as import attributes and new module types roll out across various browser platform implementations.
Security
This feature is intended to address the security concern described in https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwebcomponents%2Fissues%2F839&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077563397&amp;sdata=KNSMPFzOy5mYyZ0zN3FYRaB4L6OR8WhWEjzR3I8WC%2FI%3D&amp;reserved=0. Aside from that, the feature does not have any particular security concerns. See the TAG security and privacy review (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftc39%2Fproposal-import-assertions%2Fblob%2Fmaster%2Ftag-security-and-privacy.md&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077573391&amp;sdata=Lk7NmutElXXtVh9VopFQPZeFFP8RiZ1S5Y96B9QA2q4%3D&amp;reserved=0)
Goals for experimentation
Validate this feature as a prerequisite for JSON and CSS Modules.
Ongoing technical constraints
None
Debuggability
No special debuggability support needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
No
Tracking bug
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1132413&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077573391&amp;sdata=N0KY93S6GYOJiNRLj%2BjgtmJsosk0mGcaWf3aMurlbMs%3D&amp;reserved=0
Link to entry on the Chrome Platform Status
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.chromestatus.com%2Ffeature%2F5765269513306112&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077573391&amp;sdata=VGGBnU6peByABubBseVOiCCbFQ9%2FqTyDr%2BI40hgo0ic%3D&amp;reserved=0
Additional Note
If there are no objections we’d like to ship the import assertions syntax in V8 without gating it behind a flag.  The Import Assertions proposal is unlikely to have major changes at this point, and there’s little risk of users taking dependencies on this syntax until features that actually use it (e.g. new module types) are released in a non-experimental manner.  The JSON and CSS modules prototypes are still behind an experimental flag, and any plan to support them by default would be announced separately.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mailto:blink-dev+...@chromium.org.
To view this discussion on the web visit https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fchromium.org%2Fd%2Fmsgid%2Fblink-dev%2FMW2PR00MB0315C274F206795703884D08C5351%2540MW2PR00MB0315.namprd00.prod.outlook.com%3Futm_medium%3Demail%26utm_source%3Dfooter&amp;data=02%7C01%7Cdaniec%40microsoft.com%7C095817ef409e46bc535308d8648cc660%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369903077573391&amp;sdata=kAE6axeQdxMFefg%2FuUdq%2Fhv7lL%2FfFrkooGgPWImNBhA%3D&amp;reserved=0.

Daniel Bratell

unread,
Sep 30, 2020, 1:51:12 PM9/30/20
to Domenic Denicola, Daniel Clark, blink-dev, s...@chromium.org
I have no objections to shipping it, though I kind of agree with Dominic
regarding the timing. That having the feature before json modules seem a
bit unnecessary but maybe I am missing something?

/Daniel

Shu-yu Guo

unread,
Sep 30, 2020, 2:03:19 PM9/30/20
to Daniel Bratell, Domenic Denicola, Daniel Clark, blink-dev
For Chrome, I'm not sure what shipping import assertions in JS without also shipping the HTML integration (e.g. CSS modules) would even mean. Perhaps only the empty assertion form, i.e. `import "foo" assert { }` would be accepted, as any other semantics is defined by the JS host (the browser in this case).

For V8 itself, it might make sense to ship to import assertions for Node to hook into, if Node so wishes to make use of them. I have heard that there's desire to align with the web here, and am unsure if there're other independently motivated use cases for them.

Dan Clark

unread,
Sep 30, 2020, 7:58:07 PM9/30/20
to blink-dev, s...@chromium.org, d...@domenic.me, Daniel Clark, blink-dev, Daniel Bratell
The advantage I had in mind of shipping import assertions from the start would just be simplicity (one less flag to manage), since they don't do much without the new module types.  Since Domenic and Shu pointed out a way to tie V8 flags to Blink flags, I'm happy to just keep import assertions off by default at first and have it be automatically switched on by the JSON and/or CSS modules experimental flags.  If we see demand from Node we can turn it on by default then, or it will ship at the same time as JSON or CSS modules, whichever comes first.

Daniel Bratell

unread,
Oct 1, 2020, 3:20:17 PM10/1/20
to blink-dev, Dan Clark, s...@chromium.org, d...@domenic.me, blink-dev, Daniel Bratell
Ok, then we from the API OWNERS side will consider this shipping intent on hold/withdrawn until later, possibly as a part of JSON modules when they are to ship.

/Daniel

Reply all
Reply to author
Forward
0 new messages