Page MenuHomePhabricator

ResourceLoader JavaScript parser should allow ES6 syntax features
Open, LowPublic

Tokens
"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.
Assigned To
None
Authored By
Schnark, Nov 24 2014

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

Schnark created this task.Nov 24 2014, 9:01 AM
Schnark raised the priority of this task from to Needs Triage.
Schnark updated the task description. (Show Details)
Schnark changed Security from none to None.
Schnark added a subscriber: Schnark.
Rillke added a subscriber: Rillke.Dec 11 2014, 1:14 PM

The JSParser is part of the lib jsminplus.php. MediaWiki is using version 1.4 which seems the last one.

Seems to need an upstream bug report?

Aklapper triaged this task as Lowest priority.Mar 17 2015, 10:36 AM
Aklapper added a subscriber: Aklapper.

I don't oppose allowing ES6 syntax in user scripts.

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.

However note that it is (for better or worse) quite common for wikis to user scripts from MediaWiki:Common.js. I would agree this is a bad habit, but that is the reality at the moment and may factor in with a decision on this subject.

Krinkle renamed this task from Don't throw errors for user scripts using ES6 features to ResourceLoader JavaScript parser should allow ES6 syntax features .Apr 22 2015, 8:01 PM
Ricordisamoa added a subscriber: Ricordisamoa.
ori raised the priority of this task from Lowest to Low.Sep 18 2015, 9:03 PM
ori added a subscriber: ori.

Blocked by T102578, for the reasons mentioned in T96901#1654753.

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.Tue, Nov 12, 5:47 PM