Given that regex stuff requires dropping support for that many Safari versions, is it maybe possible to allow all ES2018 features except for the regex ones? (Do Peast and ESLint support such a hybrid approach?) I personally use the spread operator outside of MediaWiki all the time, but hardly ever do I use advanced regex features.

In T395347#10904522, @Tacsipacsi wrote:

(Do Peast and ESLint support such a hybrid approach?)

ESLint does support that via eslint-plugin-es-x.

Looks like Safari 16.4 was released on March 27, 2023. Yeah, that is a bit of a problem in terms of delaying this ticket. It could be many years before it makes sense for us to drop grade A support for Safari <16.4.

I do lean towards doing these tickets one entire ES version at a time though.

In T395347#10905257, @Bhsd wrote:

In T395347#10904522, @Tacsipacsi wrote:

(Do Peast and ESLint support such a hybrid approach?)

ESLint does support that via eslint-plugin-es-x.

Peast supports this as well. Although Peast's ES2018 features class makes no mention of the regexp features, so maybe it doesn't validate regexes?

In T395347#10915356, @SD0001 wrote:

[…]
Peast supports this as well. Although Peast's ES2018 features class makes no mention of the regexp features, so maybe it doesn't validate regexes?

I've reported this at https://github.com/mck89/peast/issues/71.

spread operator [... ]

We already use this quite a bit, e.g. in this November 2024 change. If it’s supposed to be unsupported then we might have a bug in our ESLint config? But on the other hand, mediawiki.jqueryMsg is a pretty widely used module, so if we haven’t heard any error reports from users about this spread usage, then I guess it’s actually fine in all the browsers we care about.

(Our eslint config also allows spread usage when destructuring arrays, like const [ first, ...rest ] = [ 'a', 'b', 'c' ]; however, it does not allow spread usage when destructuring objects yet, i.e. const { x, ...rest } = { x: 'X', y: 'Y' } is not yet supported.)

Looks like the spread operator for arrays is ES6, and spread operator for objects is ES2018. I've edited the ticket to clarify this.

https://nitayneeman.com/blog/object-rest-and-spread-properties-in-ecmascript-2018/

Possibly related: https://gerrit.wikimedia.org/r/c/mediawiki/libs/Minify/+/1195387

Anyone available to review it? It's had multiple +1's for awhile.

These are the differences in browser support based on MDN data via caniuse.com (we'll confirm this later in BrowserStack when we review and verify the proposed startup.js patch, for planning purposes we can start by assuming that MDN is correct).

Cells with a dash represent no change (minimum version is less then or equal to the current feature test in startup.js).

Non-empty cells represent a raising of the Modern requirements (meaning that a Grade C browser goes from receiving Modern to receiving Basic).

Bolded non-empty cells represent dropping support from Grade A.

If you're looking these up on MDN yourself, make sure not to mistake "Named capture group" (ES2018) for "Named capture groups - Duplicate names allowed" (ES2025), which I almost did because I searched for "capture groups" (plural) which retunred only found the latter.

The biggest impact here would be the Safari and iOS requirements. Apple did not release lookbehind until 2023, five years after the feature reached TC39 Stage 4 and was included in the ES2018 spec. So even though we'd raise the specification by only one year (ES2017 to ES2018), and we last raised this exactly a year ago, it actually involves dropping support for a 5-year gap in operating system support for devices sold by Apple, which translates to 3 years of iPhone models and 7 years of Mac models.

Expected Windows or Android impact

None, this time around.

Expected iPhone impact

The oldest supported device for iOS today, is the iPhone 5s which can run iOS 12.4.

Our cut-off would move to iPhone 8 and iPhone SE2, which can run iOS 16 or later. The following devices would thus no longer receive MediaWiki Grade A, because the latest OS version released by Apple for them is between iOS 11.x and iOS 15.x. Apple does not support iOS 16 on these. Ref https://en.wikipedia.org/wiki/IPhone#Models:

• iPhone 5s (sold until 2016)
• iPhone 6 (sold until 2018)
• iPhone 6s (sold until 2018)
• iPhone SE (sold until 2018)
• iPhone 7 (sold until 2019)

Expected MacBook and iMac impact

Similarly for MacBook Air and MacBook Pro, we would require Safari 16 which is available on macOS 12 and later.

Oldest supported today, with Safari 11 from macOS 10.11 El Capitan:

• MacBook Air 2008.
• MacBook Pro Mid-2007
• iMac Mid-2007

New minimum, with Safari 16 from macOS 12 Monterey:

• MacBook Air 2015
• MacBook Pro Early-2015
• iMac Late-2015

We would drop Grade A for the latest macOS/Safari on the following devices, per https://en.wikipedia.org/wiki/Safari_(web_browser)#Safari_11, https://en.wikipedia.org/wiki/MacBook_Air#Supported_operating_systems, https://en.wikipedia.org/wiki/MacBook_Pro#Supported_operating_systems, and https://en.wikipedia.org/wiki/IMac#Supported_operating_systems:

• MacBook Air 2008
• MacBook Air 2009 - 2013
• MacBook Air 2014 (stuck with Safari 15 from macOS 11 Big Sur)
• MacBook Pro Mid-2007
• MacBook Pro 2008 - 2013
• MacBook Pro Mid-2014 (stuck with Safari 15 from macOS 11 Big Sur)
• iMac Mid-2007
• iMac 2008 - 2013
• iMac Mid-2015

(Note, macOS devices do have the option of switching to Firefox or Chrome upto certain point).

I've analyzed T419142 for ES2019 as well, and that requires no support changes compared to today beyond Safari 12, basically the same as this task for ES2018 — except for the lookbehind feature that Apple didn't ship until Safari 16.4.

I recommend the following:

• raise the bar from ES2017 to ES2019 in one go, because they involve the same browser requirements. In practical terms that means we require iOS 12/Safari 12, and drop support for iOS 11/Safari 11. (The minifier is ready for both today, thanks to @SD0001!).
• exclude the RegExp lookbehind from our requirements, enforced by ESLint. This is similar to what we did last time, when we included Promise.finally from ES2018 in our requirement despite overall requiring ES2017, because that reflected the browser landscape. This is recommended by upstream ESLint (discussion) and implemented as no-regexp-lookbehind-assertions.

This would have no impact on iPhone models (Apple's cut-off went from iOS 10 to iOS 12), and drop the following Mac devices (Safari 11 from macOS 10.11 > Safari 12 from macOS 10.12):

• MacBook Air 2008, 2009. Requiring MacBook Air 2010.
• MacBook Pro 2007, 2008, 2009. Requiring MacBook Pro 2010.
• iMac 2007, 2008. Requiring iMac 2009.

We can revisit RegExp lookbehind next year as part of T429706: Raise Grade A JavaScript requirement from ES2019 to ES2020 (ECMAScript 11). This would not make us lag behind our cadence, since we're actually leaping two years ahead at once with this proposal, and that gain would stay within us. It just "evens out the service" a bit by not punishing users for Apple's decade-long underinvestment in WebKit. Apple has caught up since and will hopefully keep up going forward.

Your listings don’t include iPads and iPod Touch devices, was this intentional?

• Per https://en.wikipedia.org/wiki/IPod_Touch#Models, raising Modern to iOS 12 would mean no change to iPod Touch, while raising it to iOS 16 would exclude both the sixth and the seventh, last generation of iPod Touch (i.e. raising to iOS 16 would completely exclude iPod Touch from Modern).
• Per https://en.wikipedia.org/wiki/List_of_iPad_models, raising Modern to iOS 12 would mean no change to iPad, while raising it to iPadOS 16 (I guess iOS and iPadOS feature the same WebKit versions) would exclude iPad Mini 2–4 and the first two generations of iPad Air (but no generations of iPad and iPad Pro).

Tagging CodeMirror, since a call to Peast::ES2017 is included in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CodeMirror/+/refs/heads/master/includes/JavaScriptValidator.php

In T395347#12038096, @Tacsipacsi wrote:

Your listings don’t include iPads and iPod Touch devices, was this intentional?

[…]

Yes, in so far that my list wasn't intended to be exhaustive or complete. The idea is that iPhone represents the majority of the mobile device market for Apple and, and iMac/MacBook represent the desktop market (with I chose iMac for representing a more conservative audience where devices are supported/used longer than laptops).

Unless iPod Touch or iPad support length from Apple look significantly different, or have outsized importance for MW/WMF, it didn't seem worth including as it wouldn't change our timeline or decision. By comparison, we don't look at desktop hardware for Windows at all, and for Android I've limited my work on the "Practical implications" table to Samsung Galaxy, Google Nexus, and Moto G as samples to assess reachability/impact. There are countless more we could include, but I think I'm probably already over-doing this a fair bit out of personal curiosity. I figured I'd include some world relatable examples to help understand the practical impact here.

The other factor here is that we're talking about Modern support (Grade A), not Basic support. For readers, this has little to no impact. When we drop Basic for iOS 12-16, I expect we'll go a bit deeper.

In T395347#12038096, @Tacsipacsi wrote:

[…] raising it to iOS 16 would exclude […] last generation of iPod Touch (i.e. raising to iOS 16 would completely exclude iPod Touch from Modern).

I hadn't considered we'd reach the last gen of iPod Touch. Nice catch!

TLDR: Are we ready to drop iPhone 5s-7 (2016-2019), iPod Touch (all generations, incl the 2019-2022 last gen), and Macs 2007-2015 from Modern? Or shall we first drop 2007-2009 Macs and revisit the bigger step next year?

I would suggest keeping it to Safari 12/iOS 12. Raising the requirements all the way to Safari 16.4/iOS 16.4 seems a bit drastic as the only feature we gain from them is regexp lookbehinds, which isn't particularly interesting.

Or shall we first drop 2007-2009 Macs and revisit the bigger step next year?

Yes, but it's worth noting that the 2007 MacBook Pro and late 2008 MacBook Air both support running Chrome upto 103, which will meet the feature tests despite not being considered Grade A.

In T395347#12056373, @Krinkle wrote:

In T395347#12038096, @Tacsipacsi wrote:

Your listings don’t include iPads and iPod Touch devices, was this intentional?

[…]

Yes, in so far that my list wasn't intended to be exhaustive or complete. The idea is that iPhone represents the majority of the mobile device market for Apple and, and iMac/MacBook represent the desktop market (with I chose iMac for representing a more conservative audience where devices are supported/used longer than laptops).

Unless iPod Touch or iPad support length from Apple look significantly different, or have outsized importance for MW/WMF, it didn't seem worth including as it wouldn't change our timeline or decision.

I see.

By comparison, we don't look at desktop hardware for Windows at all, and for Android I've limited my work on the "Practical implications" table to Samsung Galaxy, Google Nexus, and Moto G as samples to assess reachability/impact. There are countless more we could include, but I think I'm probably already over-doing this a fair bit out of personal curiosity. I figured I'd include some world relatable examples to help understand the practical impact here.

The Apple landscape is a bit different. On Windows (and Linux), I’ve never heard the argument “I must throw out this computer because the last OS to support it is EOL” before 2025 – with the standard 10-year support of Windows and it supporting hardware released long before the respective Windows version, the constrain used to be the hardware lifetime, not the OS support timeframe. (This has changed with the EOL of Windows 10, since Win11’s requirement for TPM 2.0 left many devices unsupported; but we’re not even close to dropping Modern support for Win10 browsers.) Also, there are no really widespread Windows computer models, the market is more heterogeneous than even Android, let alone Apple devices, so there’s simply nothing to look at.

While there are some widespread models, the Android market is also heterogeneous with a long tail, so it’s impossible to list all Android devices. In contrast, Apple has just a handful of product lines, so it is possible to list all affected Apple devices. So IMO getting a complete picture is worth listing a few more product lines.

The other factor here is that we're talking about Modern support (Grade A), not Basic support. For readers, this has little to no impact. When we drop Basic for iOS 12-16, I expect we'll go a bit deeper.

I know it’s about Modern support, but my perception is that Modern support is – unfortunately – getting more and more important lately, in particular with the adoption of Codex/Vue. This affects editors in first line (e.g. Special:Block is completely broken without JS since the multi-blocks rewrite; the Wikidata statement editing UI has never worked without JS), but some features important to readers also rely on JavaScript: autocomplete search (no-JS Vector 2022 defaults to “go” if there’s a perfect match, while no-JS Vector 2010 used to default to full-text search – if a reader doesn’t know they have to go Special:Search, they may be unable to do a full-text search without JavaScript) or client preferences (font size, dark mode), for example. Compared to the rest of the Web, MediaWiki is doing a pretty good job in supporting very old software/hardware, but not as good as its older self.

Browser usage per https://analytics.wikimedia.org/dashboards/browsers/:

Total: 0.000086% or 396K pageviews/week.

Change #1316985 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] ResourceLoader: Raise startup.js compatibility check to ES2019

https://gerrit.wikimedia.org/r/1316985

Change #1316987 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/CodeMirror@master] JavaScriptValidator: Raise allowance to ES2019

https://gerrit.wikimedia.org/r/1316987

krinkle opened https://gitlab.wikimedia.org/repos/ci-tools/browserslist-config-wikimedia/-/merge_requests/19

Release v0.9.0

Change #1316987 merged by jenkins-bot:

[mediawiki/extensions/CodeMirror@master] JavaScriptValidator: Raise allowance to ES2019

https://gerrit.wikimedia.org/r/1316987

jforrester merged https://gitlab.wikimedia.org/repos/ci-tools/browserslist-config-wikimedia/-/merge_requests/19

Release v0.9.0

Change #1318187 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] build: Bump eslint-config-wikimedia to 0.32.5

https://gerrit.wikimedia.org/r/1318187

Change #1318178 had a related patch set uploaded (by Krinkle; author: Jforrester):

[mediawiki/core@master] build: Upgrade eslint-config-wikimedia from 0.32.3 to 0.32.5

https://gerrit.wikimedia.org/r/1318178

krinkle opened https://gitlab.wikimedia.org/repos/ci-tools/libup-config/-/merge_requests/138

releases: Bump eslint-config-wikimedia to 0.32.5

jforrester updated https://gitlab.wikimedia.org/repos/ci-tools/libup-config/-/merge_requests/138

releases: Bump eslint-config-wikimedia to 0.32.5

jforrester merged https://gitlab.wikimedia.org/repos/ci-tools/libup-config/-/merge_requests/138

releases: Bump eslint-config-wikimedia to 0.32.5

Change #1318178 merged by jenkins-bot:

[mediawiki/core@master] build: Upgrade eslint-config-wikimedia from 0.32.3 to 0.32.5

https://gerrit.wikimedia.org/r/1318178

In T395347#12037648, @Krinkle wrote:

These are the differences in browser support based on MDN data via caniuse.com (we'll confirm this later in BrowserStack when we review and verify the proposed startup.js patch […] )

[…]

I put up a test page with the before/after on https://people.wikimedia.org/~krinkle/T395347-rl-feature-test-es2019.html and ran it through BrowserStack.

Everything was exactly as expected. Android 5 goes up to Chrome 95, Android 6 upto Chrome 106, Safari 11 starts to fail, Safari 12 continues to pass.

Chrome 73 (Windows 7)	Safari 11.1 (macOS 10.13 High Sierra)	Android 5 (Chrome 95)

BrowserStack:

• Chrome 49 (Windows 7): Reject > Reject
• Chrome 63 (macOS 10.12): OK > Reject
• Chrome 72 (Windows 7): OK > Reject
• Chrome 73 (Windows 7): OK > OK

• Edge 79 (Windows 7): Devices no longer available
• Edge 80 (Windows 7): OK > OK

• Firefox 58 (Windows 7): OK > Reject
• Firefox 58 (macOS 10.12): OK > Reject
• Firefox 72 (macOS 10.12): OK > Reject
• Firefox 73 (macOS 10.12): OK > Reject
• Firefox 78 (macOS 10.12): OK > OK
• Firefox 78 (Windows 7): OK > OK

• Safari 10.1 (macOS 10.12 Sierra): Reject > Reject
• Safari 11.1 (macOS 10.13 High Sierra): OK > Reject
• Safari 12.1 (macOS 10.14 Mojave): OK > OK

• Android 10 (Samsung Galery Tab S7; Chrome 149): OK > OK
• Android 10 (Samsung Galery S20; Chrome 149); OK > OK
• Android 5-9: Devices no longer available
• Android 4.x: Simulator unresponsive

• iOS 6 (iPhone 5 Sim): Reject > Reject
• iOS 7-11: Devices no longer available
• iOS 12 (iPad 6th Gen): OK > OK
• iOS 13 (iPhone 11): OK > OK
• iOS 15 (iPhone SE 2022): OK > OK

SauceLabs:

• Android 5.0 (Nexus 5 Emulator; Chrome 95): OK > OK
• Android 5.1 (Nexus 5 Emulator; Chrome 95): OK > OK
• Android 6 (Nexus 5 Emulator; Chrome 106): OK > OK
• Android 7.1 (Nexus 6 Emulator; Chrome 119): OK > OK
• Android 9 (Pixel 3 Emulator; Chrome 136): OK > OK

Change #1316985 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: Raise startup.js compatibility check to ES2019

https://gerrit.wikimedia.org/r/1316985

Doc updates:

• https://www.mediawiki.org/w/index.php?title=Compatibility&diff=8540290&oldid=8527134
• https://www.mediawiki.org/w/index.php?title=Template%3ACompatibility_browser&diff=8540292&oldid=8482458