It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

A test exemption is reasonable because we don't have infra to test on ancient versions of iOS Safari.

can we test this by scanning the code for patterns known to not work in old Safaris we want to support?

if not:
test-exempt: intractable

can we test this by scanning the code for patterns known to not work in old Safaris we want to support?

@Hixie I tried to use eslint + eslint-plugin-compat specifying the browsers we want to support, and it wasn't very trust-worthy. If eslint was adjusted to recognize the syntax (es2022) for the browsers that would support it to pass, the compat plugin wouldn't complain about it for Safari 13. This would have also required to bring node as a build dependency (or to somehow shrink-wrap the eslint tool, which I'm not sure is possible).

I also looked at esbuild, which seems more promising, because you can feed it JS written in any syntax level, and it'll automatically transform it to something that complies with a specific target (targets can be es6 but also safari 13, or a combo of them), even minify it, so this might stop being a problem altogether. I've created an issue to dive deeper into that option here: #104777 (which could be a great package for post-processing of the web assets).

For now, I'm going to land this, but it is true that there's more changes coming here that are hard to test (if at all possible)

(PS: Another way of handling this is converting flutter.js in a node package, maintained separately from flutter/flutter_tools, but that might be overkill)