Intent to Prototype: Deprecate and remove import assertion 'assert' syntax
Shu-yu Guo
Contact emails
s...@chromium.org, nrib...@igalia.comExplainer
NoneSpecification
https://tc39.es/proposal-import-attributesSummary
TC39 has consensus for trying to deprecate and remove the `assert` keyword in favor of the new `with` keyword in import attribute syntax. That is, `import m from 'foo' assert { type: 'json' }` will now throw a SyntaxError, and developers must change to `import m from 'foo' with { type: 'json' }`. https://github.com/tc39/proposal-import-attributes/issues/135
Blink component
Blink>JavaScript>LanguageMotivation
The import assertions proposal (now called "import attributes") [1] in TC39 shipped in M91 with the `import mod from 'foo' assert { type: 'json' }` syntax. The original semantics was that additional information following the `assert` keyword cannot cause the module to be reinterpreted or change the semantics of the module in any way, i.e., a pure assertion. Following an HTML integration issue with CSP [2] that required changing Accept headers depending on the requested module type, TC39 reached consensus that the "pure assertion" semantics are to be relaxed to allow reinterpretation, and that the `assert` keyword be changed to `with` to reflect the new semantics. [1] https://github.com/tc39/proposal-import-attributes/ [2] https://github.com/whatwg/html/issues/7233
Initial public proposal
NoneTAG review
NoneTAG review status
Not applicableRisks
Interoperability and Compatibility
There is no interoperability risk because Safari and Firefox never shipped the `assert` syntax. There is compatibility risk within Chrome as we shipped in M91.
Gecko: N/A
WebKit: N/A
Web developers: No signals
Other signals:
Ergonomics
None.
Activation
None.
Security
None.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None.
Is this feature fully tested by web-platform-tests?
In test262Flag name on chrome://flags
--harmony-import-assertionsFinch feature name
NoneNon-finch justification
Use counter metric shows current usage at 0.0002% https://chromestatus.com/metrics/feature/timeline/popularity/4528 Additionally, analysis shows that sites that do use it have fallbacks: https://github.com/tc39/proposal-import-attributes/issues/135#issuecomment-1625217926 This data suggests that a finch trial is not needed, and a clean removal is possible.
Requires code in //chrome?
FalseEstimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4689167795879936
Mike Taylor
[noting that the subject is a typo, hence my edit in the subject
line]
Contact emails
s...@chromium.org, nrib...@igalia.com
Explainer
None
Specification
https://tc39.es/proposal-import-attributes
Summary
TC39 has consensus for trying to deprecate and remove the `assert` keyword in favor of the new `with` keyword in import attribute syntax. That is, `import m from 'foo' assert { type: 'json' }` will now throw a SyntaxError, and developers must change to `import m from 'foo' with { type: 'json' }`. https://github.com/tc39/proposal-import-attributes/issues/135
Blink component
Blink>JavaScript>Language
Motivation
The import assertions proposal (now called "import attributes") [1] in TC39 shipped in M91 with the `import mod from 'foo' assert { type: 'json' }` syntax. The original semantics was that additional information following the `assert` keyword cannot cause the module to be reinterpreted or change the semantics of the module in any way, i.e., a pure assertion. Following an HTML integration issue with CSP [2] that required changing Accept headers depending on the requested module type, TC39 reached consensus that the "pure assertion" semantics are to be relaxed to allow reinterpretation, and that the `assert` keyword be changed to `with` to reflect the new semantics. [1] https://github.com/tc39/proposal-import-attributes/ [2] https://github.com/whatwg/html/issues/7233
Initial public proposal
None
TAG review
None
TAG review status
Not applicable
Risks
Interoperability and Compatibility
There is no interoperability risk because Safari and Firefox never shipped the `assert` syntax. There is compatibility risk within Chrome as we shipped in M91.
Gecko: N/A
WebKit: N/A
Web developers: No signals
Other signals:
Ergonomics
None.
Activation
None.
Security
None.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
None.
Is this feature fully tested by web-platform-tests?
In test262
Flag name on chrome://flags
--harmony-import-assertions
Finch feature name
None
Non-finch justification
Use counter metric shows current usage at 0.0002% https://chromestatus.com/metrics/feature/timeline/popularity/4528 Additionally, analysis shows that sites that do use it have fallbacks: https://github.com/tc39/proposal-import-attributes/issues/135#issuecomment-1625217926 This data suggests that a finch trial is not needed, and a clean removal is possible.
Thanks for the analysis! From the 14 sites that were looked at we have:
Minor breakage:
- var.blog.jp: some missing syntax highlighting
- council.csie.ntu.edu.tw: filtering doesn't work, but all people are visible by default
- registrs.ur.gov.lv: missing version number in footer
- sanlam.ma/fr/professionnel/: autocomplete for contact form
breaks (site might feel this is major?)
Major breakage:
- classlocator.live: search stop working. Given the whole point of the site is to search for classes... we might categorize as Severe breakage.
- labdash.net: a map of testing locations doesn't work. Seem not great.
- secure.labdash.net: same as above
No breakage: the rest of the 7 out of 14.
Even thought the use counter is quite small, the breakage doesn't seem insignificant (even if the sites area already busted in Firefox or Safari).
Have you thought about a deprecation period, with some
developer-facing comms or DevTools issue? Not sure that outreach
is the right option, but something else to consider.
Requires code in //chrome?
False
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4689167795879936
This intent message was generated by Chrome Platform Status.
--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e_cMbiPO2AhV%3D%3DP_r%3Dov%2BKvxyXqkyosej9a%3DuJO7zt5_Q%40mail.gmail.com.
Shu-yu Guo
Mike Taylor
LGTM to deprecate for 3 milestones, with some outreach efforts as outlined below.
Can you come back and report then to request re-review? You'll
need 3 LGTMs to actually remove, but for now you're good w/ the
deprecation. Good luck on getting the message out!
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b9a99a67-f9fd-404d-83e3-4550c9a8b5b9%40chromium.org.
Shu-yu Guo
Rick Byers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN-e9e_oFyFdTu3_Yo5mfqVoC-CsEiXd%2B6ohnyggssy2j3-9zQ%40mail.gmail.com.
Philip Jägenstedt
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_r9XzpwOZF%2BQ6jbrYKHNurKP%3D2Z1LW%2Bu4J4Y%3DKoqhoWw%40mail.gmail.com.
Shu-yu Guo
LGTM2 for Mike's plan of deprecating for 3 milestones, doing outreach, and then revisiting this thread.If we still know of serious breakage after this, is it an option to simply support both keywords indefinitely, but treat `assert` as legacy? Documentation, linters and autoformatters could all direct developers to `with`, without breaking any existing sites.
Philip Jägenstedt
On Wed, Dec 13, 2023 at 9:03 AM Philip Jägenstedt <foo...@chromium.org> wrote:LGTM2 for Mike's plan of deprecating for 3 milestones, doing outreach, and then revisiting this thread.If we still know of serious breakage after this, is it an option to simply support both keywords indefinitely, but treat `assert` as legacy? Documentation, linters and autoformatters could all direct developers to `with`, without breaking any existing sites.Yes, it is an option to support both keywords indefinitely and treat `assert` as legacy. TC39 consensus includes `assert` legacy support, on account of Chrome having shipped in good faith. We're trying to remove it for maximal interop since no other browsers shipped `assert`, but if it's not feasible it will not be a willful violation of spec to continue shipping it.
Daniel Bratell
LGTM3 for the plan as outlined by Mike and Philip.
/Daniel
--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYetzaKxSi_yWTCHd4xJrLh1OAY4YQBdwEN1cHd22kUnoA%40mail.gmail.com.
