Page MenuHomePhabricator

Allow ES6 syntax features in gadgets and other site-wide scripts
Open, LowPublic

Assigned To
None
Authored By
Schnark
Nov 24 2014, 9:01 AM
Tokens
"Like" token, awarded by Silent."Like" token, awarded by Masumrezarock100."Mountain of Wealth" token, awarded by Daimona."Like" token, awarded by TerraCodes."Like" token, awarded by Shreyasminocha."Like" token, awarded by Vedmaka."Doubloon" token, awarded by Yair_rand."Like" token, awarded by MichaelSchoenitzer."Yellow Medal" token, awarded by Ricordisamoa.

Description

Steps to reproduce:

  1. Open your Special:MyPage/common.js for editing, add the code
var val, a = ['a', 'b'];
for (val of a) {
	console.log(val);
}
  1. Preview your change. The console should show "a" and "b" (given your browser support that much of ES6, but most browsers should, by now).
  2. Save the page.

Expected result: Same as step 2.
Actual result: The code from common.js is replaced with code that just throws an error:
Error: JavaScript parse error: Parse error: Unexpected token; token ; expected in file 'Benutzer:Schnark/common.js' on line 5

While for the site wide MediaWiki:Common.js etc. this is a good feature (to make sure nobody accidentally puts in some ES6 features only available in his browser but not in other users' browser), for personal JS a user should not be prevented to use whatever features his browser is able to provide.

Workaround

See T75714#4674421.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Ltrlg added a subscriber: Ltrlg.Nov 6 2015, 5:08 PM
Boshomi added a subscriber: Boshomi.Jul 2 2016, 8:36 AM

Meanwhile the most important Browsers (FF47, Chrome51, Edge13 ) supports ES6 < https://kangax.github.io/compat-table/es6/> so the priority should be higher than "low".
Only IE is a pain, and will be a pain for a long time (no feature upgrades no new version, Edge is not available for Windows 8.1 and older).

While we should probably have a way to disable validation for user scripts - for general allowance of ES6 syntax in ResourceLoader (core, extension, site-wide scripts), this is blocked on enforcing ES6 support in all Grade A browsers.

Right now we're not even seeing ES5 support everywhere (though we'll soon require ES5 for Grade A browsers through our feature-test, per T128115).

At that point, T96901 is still blocked on a new parser and minifier, however.

And when using the future no-invalidation flag in user scripts, we'd also have to disable minification.

Yair_rand added a subscriber: Yair_rand.
Restricted Application added a project: Performance-Team. · View Herald TranscriptJan 22 2018, 1:09 PM

Merging T96901 into this task because I do not think we should invest effort into a new parser for ES5. Instead, we should work towards a parser capable of ES6 syntax (which automatically supports ES5 syntax).

I have also removed the sub task for requiring ES6 for MediaWiki Grade A code because that can be enforced statically via ESLint already. It does not prevent us from being able to parse and validate ES6 syntax in user scripts or other opt-in areas.

I have also removed the sub task for requiring ES6 for MediaWiki Grade A code because that can be enforced statically via ESLint already. It does not prevent us from being able to parse and validate ES6 syntax in user scripts or other opt-in areas.

Once the minifier is able to handle ES6, sooner or later some common.js (or default gadget) will start to use ES6 syntax and thus break in older browsers.

While ESLint can force ES5 compatibility for core JS, it can't do so for site JS.

@Schnark Indeed. For wiki modules such as the 'site' module (and perhaps default-on gadgets) we may want to keep using the old parser for validation, or perhaps the new parser will have an option to decide what ecmaVersion to allow and we could pin those to ES5.

For example, ESLint uses an ES7-compatible parser, but has modes to only allow ES3, ES5 or ES6 features.

Krinkle added a comment.EditedOct 17 2018, 3:15 PM

Under MW 1.29.1, if I insert a template literal (surrounded by backticks) into a script in the MediaWiki namespace, the ResourceLoader gives a parse
error.

You can disable this ES3 validation step with the $wgResourceLoaderValidateJS configuration variable. Which should make it so that you can use ES6 syntax on your wiki.

Please note that this feature does exist for a reason, and disabling it may have certain side effects. Most notably, it means that

  1. People that visit your wiki using older browsers (those without full ES6 support) will have no interactive features at all (not even basic stuff like search suggestions, or collapsible tables). And if they are using Internet Explorer or Opera, the browser may also tell the user that the website is broken "Script error".
  2. If an administrator on your wiki makes a mistake and saves an edit to Common.js with a syntax error, all interactive feature will be broken for all users, including users with modern browsers.

When the ValidateJS feature is left enabled (as is the default), these issues don't happen because it will have found the syntax on these wiki pages before the code is combined. It then substituted the broken script with a valid script that simply logs a message to the console - thus preserving the integrity of the JavaScript bundle overall, and with that other features.

Krinkle updated the task description. (Show Details)Oct 17 2018, 3:15 PM
Vedmaka added a subscriber: Vedmaka.
Daimona added a subscriber: Daimona.Feb 8 2019, 1:33 PM
fbstj added a subscriber: fbstj.Mar 4 2019, 10:29 AM
TheDJ added a subscriber: TheDJ.Jul 30 2019, 8:11 AM
Pcj added a subscriber: Pcj.Nov 12 2019, 5:47 PM
Restricted Application added a subscriber: RhinosF1. · View Herald TranscriptDec 18 2019, 11:51 AM
AnneT added a subscriber: AnneT.Dec 18 2019, 2:04 PM
Tgr added a subscriber: Tgr.Dec 18 2019, 7:03 PM

I think the only significant browser that does not support ES6 today (apart from some very fringe ES6 changes which are less widely supported but no one ever uses, like a slightly different set of unicode characters allowed in identifiers) is IE 11, which is currently ~3% of our traffic. Which is large enough not to break, but small enough not to optimize for. Maybe we could allow modern syntax and transpile it to a legacy version for old browsers (using Babel or something like that)? There probably won't be any PHP library we can use, but for Wikimedia sites, it could be done via a service / local executable, and for sites on shared hosting who can't make use of such functionality, the loss of IE 11 users seems acceptable.

(The other option would be transpiling statically, which is I think what the WMF Web team has adopted. For gadgets, that's probably not workable though.)

(The other option would be transpiling statically, which is I think what the WMF Web team has adopted. For gadgets, that's probably not workable though.)

Well, that’s what I currently do for the AC/DC gadget. I might be the only one, though :)

AnnAngela added a comment.EditedJan 28 2020, 2:32 AM

Although setting the $wgResourceLoaderValidateJS to false is too dangerous, why not add a feature to support validating es6 or higher version JS for the site which dont care about IE visitor?

@AnnAngela This task is not blocked on deciding how to implement it. It is blocked on the cost of implementing the feature in question. That will require an engineer to spent significant amounts of time to work on that. That engineer is likely to be me at some point. I have other priorities at the moment. This will not become my priority until after it becomes useful for Wikipedia to enable such feature.

Pietrodn removed a subscriber: Pietrodn.Feb 4 2020, 11:07 PM
Silent added a subscriber: Silent.
Krinkle renamed this task from ResourceLoader JavaScript parser should allow ES6 syntax features to Allow ES6 syntax features in gadgets and other site-wide scripts.Jun 16 2020, 3:39 PM