Page MenuHomePhabricator

Raise Grade A JavaScript requirement from ES2016 (ES7) to ES2017 (ES8)
Closed, ResolvedPublic

Description

T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015) | T395347: Raise Grade A JavaScript requirement from ES2017 to ES2018

Motivation

This ticket is to raise the Grade A requirement for the Modern JS layer, from ES2016 (aka "ES7") to the next milestone ES2017 ("ES8").

The primary motivation is native use of async-await syntax, as introduced in ES2017.

See also Promises and Async functions in Exploring JavaScript by Axel Rauschmayer.

Before
function createQuux() {
  return getFoo
    .then(function (foo) {
      // ···
      return getBar();
    })
    .then(function (bar) {
      // ···
      return barToBaz(bar);
    })
    .then(function (baz) {
      // ···
      return Quux.newFromBaz(baz)
        .catch(function (error) {
          // ···
          return false;
        });
    })
}
After
async function createQuux() {
  const foo = await getFoo();
  const bar = await getBar();
  const baz = barToBaz(bar);
  try {
    return await Quux.newFromBaz(baz);
  } catch (error) {
    return false;
  }
}

JavaScript features:

  • ES7 / ES2016
    • ** (exponential operator, to the power of)
    • Array.includes()
  • ES8 / ES2017
    • async / await
    • Object.values()
    • Object.entries()
    • Object.getOwnPropertyDescriptors()
    • String.padStart(), String.padEnd()
    • shared memory and atomics
    • trailing commas
Blockers
Todo

Once unblocked:

  1. ResourceLoader:
    • update startup.js to raise feature tests requirement to ES2017 (patch)
    • update Peast call in Module::validateScriptFile() to allow ES2017 in Gadgets and user scripts (patch)
  2. eslint-config-wikimedia:
  3. Documentation:
Related tickets

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change #1105907 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/core@master] startup.js: Add test for Array.prototype.includes

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

This check add nothing to the status quo for major browsers. This check cuts at Chrome 47/Edge 14/Safari 9/Firefox 43 where the status quo is Firefox 58+, Safari 11.1+, Chrome 63+ and Edge 79+.

To reduce unnecessary codes we should remove unnecessary feature check, e.g. the whole https://gerrit.wikimedia.org/g/VisualEditor/VisualEditor/+/dfb712599d4e4c59dff56836529f9b99c1ac526e/src/init/ve.init.SupportCheck.js should be dropped.

Related, I wonder why we don't take more advantage of polyfills. Array.prototype.includes() for example is a tiny implementation, and would make JS developer life so much easier.

We did have polyfill for Array.prototype.includes() as part of the module es6-polyfills, but it was removed in rMW89c70b4c3936: es6-polyfills: Remove scripts, replace with deprecated stub (T178356). Given all browsers where JS runs already support includes(), as pointed out above, there is indeed no point in restoring it though.

This comment was removed by Esanders.
Krinkle renamed this task from Raise Grade A JavaScript requirement from ES6 (2015) to ES7 (2016) to Raise Grade A JavaScript requirement from ES2015 (ES6) to ES2016.Jan 4 2025, 1:44 AM
Krinkle updated the task description. (Show Details)
Krinkle renamed this task from Raise Grade A JavaScript requirement from ES2015 (ES6) to ES2016 to Raise Grade A JavaScript requirement from ES2015 (ES6) to ES2017.Jan 4 2025, 9:58 PM
Krinkle updated the task description. (Show Details)
Novem_Linguae renamed this task from Raise Grade A JavaScript requirement from ES2015 (ES6) to ES2017 to Raise Grade A JavaScript requirement from ES2015 (ES6) to ES2017 (ES8).Jan 30 2025, 2:26 AM
Novem_Linguae updated the task description. (Show Details)

@Novem_Linguae: Can you explain why you just moved the goalposts on this work? Getting management sign-off is not made faster when the target changes and people might have to re-start.

@Jdforrester-WMF I think the goalposts were already moved from ES7 to ES8 on January 4 by someone from WMF. Please see ticket edit history. My edit on January 29 just brought the ticket in alignment with that edit.

I wouldn't mind moving the goalposts back to ES7. That's what I had the ticket at originally. That's probably above my pay grade though :)

@Jdforrester-WMF I think the goalposts were already moved from ES7 to ES8 on January 4 by someone from WMF. Please see ticket edit history. My edit on January 29 just brought the ticket in alignment with that edit.

Aha, thanks.

I wouldn't mind moving the goalposts back to ES7. That's what I had the ticket at originally. That's probably above my pay grade though :)

Yeah, sorry for the slowness here.

Krinkle renamed this task from Raise Grade A JavaScript requirement from ES2015 (ES6) to ES2017 (ES8) to Raise Grade A JavaScript requirement from ES2016 (ES7) to ES2017 (ES8).Feb 17 2025, 11:11 PM
Krinkle updated the task description. (Show Details)
Krinkle added subscribers: alaa, ExE-Boss, Ladsgroup and 12 others.

Raise Grade A JavaScript requirement from ES2016 (ES7) to ES2017 (ES8)

When was MediaWiki's grade A requirement raised to ES7? Is there a phab ticket for that? Was https://www.mediawiki.org/wiki/Compatibility#General_information updated? Were our eslint rules updated?

If not, perhaps this should be renamed back to "Raise Grade A JavaScript requirement from ES2015 (ES6) to ES2017 (ES8)"

Raise Grade A JavaScript requirement from ES2016 (ES7) to ES2017 (ES8)

When was MediaWiki's grade A requirement raised to ES7?

It was observed in the discussion of this task that our target browsers and feature checks effectively mean we are already targetting ES2016.

Were our eslint rules updated?

Yes: https://github.com/wikimedia/eslint-config-wikimedia/releases/tag/v0.29.0

Change #1105907 abandoned by Krinkle:

[mediawiki/core@master] startup.js: Add test for Array.prototype.includes

Reason:

Redundant per https://gerrit.wikimedia.org/r/1127892 which adopts use of Array#includes.

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

Krinkle triaged this task as Medium priority.Apr 7 2025, 1:11 PM
Krinkle updated the task description. (Show Details)

Change #1141401 had a related patch set uploaded (by Hokwelum; author: Hokwelum):

[mediawiki/core@master] Resourceloader: Raise compatibility test for ES2017

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

Change #1141401 merged by jenkins-bot:

[mediawiki/core@master] Resourceloader: Raise compatibility test for ES2017

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

Change #1149768 had a related patch set uploaded (by Hokwelum; author: Hokwelum):

[mediawiki/core@master] ResourceLoader: update Peast call in Module::validateScriptFile() to ES2017

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

Change #1149768 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: update Peast call in Module::validateScriptFile() to ES2017

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

Suggested User-notice:

After Thursday, June 5, 2025, all Wikimedia wikis will allow up to JavaScript version ES2017 in their JavaScript code. This includes in MediaWiki core, extensions, gadgets, and user scripts. Previously the linter, validator, and minifier only allowed up to ES2016, and a few months before that, up to ES2015. A feature of ES2017 is async/await syntax, allowing for easier-to-read code with less nesting.

I used AI to tweak the announcement—you might find some of its changes worth picking up:

Starting Thursday, June 5, 2025, Wikimedia wikis will allow JavaScript ES2017 across all JavaScript code, including MediaWiki core, extensions, gadgets, and user scripts. Previously, the linter, validator, and minifier only allowed up to ES2016, and a few months before that, up to ES2015. One notable feature of ES2017 is async/await syntax, which improves code readability by reducing nesting.

I used AI to tweak the announcement

Please don't. Almost all of the changes proposed are actively incorrect.

The venue for proposing edits to Tech/News things is meta, so let's do that there.

Refs the Tech News page: Tech/News/2025/23. (I'm not sure why this link hasn't been added to the task description, so I didn't include it myself.)

Hokwelum updated the task description. (Show Details)

We have an issue on frwiki. Although we have been updated to 1.45.0-wmf.4 as expected, we are encountering this error:

Parse error: Unexpected: function on line 194 in MediaWiki:Gadget-C_helper_message.js

You may reproduce it by executing:

mw.loader.load( 'ext.gadget.C_helper' );

I manually confirmed that Peast::ES2016() fails to parse the code whereas Peast::ES2017() successfully parses it.

It looks like the Peast::ESxxxx() call hasn't been updated, which is quite unexpected and strange.

Any insight?

Interestingly, a user resolved the issue by modifying the relevant script to force a server-side refresh (he also first attempted a null edit, but that apparently did not solve the issue).

However, it seems problematic that such an intervention was necessary. Is there a way to enhance the process to avoid this workaround?

Edit: we no longer encounter the error on regular page views, but I just tried executing the mw.loader.load(...) on a page view using "?debug=2" query parameter, and the error still occurs!

If Wikimedia is upgraded to ES2017 except for the edge case mentioned in the two comments above, we might want to resolve this ticket, then document that issue in a separate ticket. Thoughts on copy pasting those two comments into a new ticket and dropping a link here?

The Peast call is behind a memcached key by (wiki, page title, revision hash).

If someone saved the same "new" code on the same wiki, same page title, before the upgrade, found the validation error, reverted, and now after the upgrade re-applied the edit, then the old result may still be cached for several days and be rediscovered after the upgrade.

This is remedied by bumping USERJSPARSE_CACHE_VERSION.

As a temporary workaround you can make the code page different in any kind of minor way so that it won't match the fingerprint of the old cache. Eg change a comment or a line break.

Thank you for the explanation. The USERJSPARSE_CACHE_VERSION is simply located in /includes/ResourceLoader/Module.php.

Additionally, this cache has a duration of $cache::TTL_WEEK, which, as the name suggests, equals one week.

Therefore, there is no need to bump USERJSPARSE_CACHE_VERSION or make dummy edits to scripts (which would unnecessarily clutter the page history). We simply need to wait for the week to elapse.

When using await without an async in the onwiki code editor, we get an error: Missing ";" before statement. which is unhelpful in understanding the issue.

When using await without an async in the onwiki code editor, we get an error: Missing ";" before statement. which is unhelpful in understanding the issue.

This will be resolved when we migrate from CodeEditor to CodeMirror (T373711).

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

[mediawiki/core@master] ResourceLoader: Update call to Peast in benchmark

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

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

[mediawiki/core@master] ResourceLoader: Bump USERJSPARSE_CACHE_VERSION and STORAGE_VERSION

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

Change #1158240 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: Update call to Peast in benchmark

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

Change #1158230 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: Bump USERJSPARSE_CACHE_VERSION and STORAGE_VERSION

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

I recently uploaded a new extension to Gerrit (here) and expected "wikimedia/client" to require ES8, but apparently it still requires ES7? Do extensions still require ES7, or am I missing something?

Try bumping eslint-config-wikimedia to 0.31.0 in package.json