Thanks - please do (and please follow up in this thread if things go
sideways). Good luck!
On 8/29/23 9:34 AM, Nicolò Ribaudo wrote:
Hi,
I did not plan to implement it with a flag, but adding a killswitch
just to be safe in case it turns out not to be web-compatible is easy
to do.
On 28/08/23 17:23, Mike Taylor wrote:
On 8/28/23 5:33 AM, Nicolò Ribaudo wrote:
Hello,
we are implementing a breaking change to Chromium's import
attributes implementation.
The import attributes proposal
(https://tc39.es/proposal-import-attributes/, previously known as
"import assertions") was recently updated to throw on unknown
attribute keys, rather than ignoring them. Currently the only valid
attribute is "type", defined by the HTML specification (for JSON and
CSS imports) and by https://tc39.es/proposal-json-modules/.
The previous version of this proposal has been implemented in
Chromium for two years, and we are now updating to the new semantics.
While this is technically a breaking change, the compatibility risk
is very low:
- The upper bound of import attributes usage is
https://chromestatus.com/metrics/feature/timeline/popularity/4528.
- None of the top websites listed in the link above uses unknown
attributes.
- No tool implemented attributes other than "type" (other than
TypeScript's "resolution-mode", which is only valid when using the
TS-specific import type syntax), so it's unlikely that somebody is
shipping unknown attributes thinking that they are being compiled
away by some tool.
- A typo in type would already result in an error, since type is
only used for CSS&JSON imports and it's mandatory.
- Of the 9.6k results on GitHub for import assertions usage
(/import.*assert\s*\{/
<https://github.com/search?q=+language%3AJavaScript+%2Fimport.*assert%5Cs*%5C%7B%2F&type=code>),
only 4 Node.js projects use an unknown "integrity" one (found by
manually analyzing the results for
/import.*assert\s*\{.*[^\s"'type].*:.*\}/
<https://github.com/search?q=+language%3AJavaScript+%2Fimport.*assert%5Cs*%5C%7B.*%5B%5E%5Cs%22%27type%5D.*%3A.*%5C%7D%2F&type=code>).
Most of the results with unknown attributes are tests for various
parsers or implementations.
I searched for "sha384-abc123" instead
<https://github.com/search?q=sha384-ABC123&type=code&p=1>, and found
10 Node projects using this integrity key with seemingly copypasta
sha384-abc123. It seems like your search regexp doesn't account for
keys on new lines (probably possible w/ github search?). Maybe worth
double checking to see if nothing new pops up.
(Also, might be nice to file issues and let folks know their projects
are going to break, especially if the number is this small.)
As such, this change is safe to ship.
Are you implementing behind a feature flag, in case it turns out to
not be safe?
You can find the ChromeStatus entry at
https://chromestatus.com/feature/5123137502445568.
Thanks,
Nicolò Ribaudo
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/192d117b-b2b9-4835-a6bd-bf5e49b64757n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/192d117b-b2b9-4835-a6bd-bf5e49b64757n%40chromium.org?utm_medium=email&utm_source=footer>.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f24f5848-cc65-4384-afea-070506c62791%40chromium.org.