ECMAScript 6? #1157

ghost · 2017-11-28T01:06:06Z

What do you guys think of refactoring the code from ES5 to ES6?

theodab · 2017-11-28T17:06:25Z

At the moment we still support IE 11, and IE 11 does not support ES6 and (presumably) never will.

Maybe at some point in the future we will stop supporting IE 11 and upgrade everything to ES6. Perhaps if, once the Shaka Player survey has ended, we find that not many people care about IE 11 support? I can't make any promises, of course.

joeyparrish · 2017-11-28T18:01:17Z

We could move to ES6 without dropping IE11 support, by changing the way we develop. Uncompiled mode is the issue. In uncompiled mode, ES6 code won't run on IE11. If we are compiling ES6 down to ES5, we can still develop in ES6 and run compiled ES5 on IE11.

joeyparrish · 2018-01-04T17:49:45Z

This will be a long transition. In particular, replacing the linter will be a giant pain.

Checklist for ES6 conversion:

Use Babel to serve ES5 in unit tests, so we can still test uncompiled code on IE11
Disallow uncompiled build in the demo app on IE11
Allow ES6 input in the compiler settings
Replace the long-deprecated gjslint with modern JS linters that understand ES6
- Refine linter settings and convert code to pass
- Reimplement property doc enforcement for typedefs (in jsdoc fork? as eslint plugin?)
Start converting library code to ES6 syntax
Polyfill some ES6 methods and lift some of the bans in build/conformance.textproto

Once we start moving to ES6, uncompiled mode stops working on non-ES6 browsers (IE11 is the only one we test on). We can disable uncompiled mode in the demo, but we still want our tests to be uncompiled. With uncompiled library & tests, we can test units that are not exported and even access private members that would otherwise be renamed. For production/demo, Babel plays no role. The Closure Compiler will take in ES6 and spit out ES3 syntax (even older than ES5, so we can at least run & fail a support check). Babel will be used by Karma to preprocess all test and library code before serving it from Karma. This will allow us to use ES6 in both the library and the tests, and still run uncompiled tests and test the uncompiled library on ES5 browsers such as IE 11. Issue #1157 Change-Id: Idd185d0e231d16b6df52babda777111e85890012

As we convert Shaka Player to ES6, we will lose the ability to run the demo app in uncompiled mode on older browsers, such as IE 11. This detects ES6 syntax support and disables the link to uncompiled mode in the demo app. It also prevents the loader from choosing uncompiled mode by default in these older browsers. Issue #1157 Change-Id: I13e3a80669daaabd38a056f5242ee713f3d014cc

Note that until we replace gjslint, the linter will still not accept ES6 syntax. So we cannot yet merge any commits which use ES6. But this should allow us to start experimenting with ES6 locally by bypassing the old linter. Issue #1157 Change-Id: Ic0902f57a34f61b0a7831c3e019425cee6e0308f

The eslint configuration is derived from analyzing the style of our sources as they are now, plus a few tweaks. In particular, we have disabled checks for undefined variables and use of console, both of which the compiler handle with greater precision. The compiler already knows what is defined in the environment through our externs, and has specific exceptions for the use of console (demo, tests). We have also disabled a few checks that we should use, but will require many changes to the code: no-unused-vars, no-redeclare, and comma-dangle. This commit also fixes several types of eslint errors that were easy: - no-useless-escape (unneccessary escape characters in Regexp) - no-constant-condition (using true/false/0/1/etc in if/while) - no-fallthrough (caught an actual bug in one EME polyfill) - no-irregular-whitespace (we had a UTF-8 nbsp in externs) - no-cond-assign (using an assignment inside a conditional) To satisfy stricter provide/require checks in the Closure Compiler Linter, we will no longer use provide/require at all in tests. We will still use provide in test utilities (test/test/util/) since it sets up the namespace for us. But we will not use require there because there is no deps management for test code. Issue #1157 Change-Id: Icc44f51feeb568ea7d3980e693e92e560d897afd

This digests and organizes many of the automatic settings in eslint, and changes several of them to be more strict. This also fixes the following errors: - array-callback-return - no-catch-shadow - no-multi-spaces - no-new - no-throw-literal - no-useless-call - no-useless-concat - no-useless-return Several checks have been organized into a group of checks we should use, but need more time to implement and fix. Some other checks have been delegated to the Closure compiler, which can more precisely whitelist exceptions. Issue #1157 Change-Id: I8fe4966959e08050f8159e6a1fee161e7d71177e

Some style rules are temporarily overridden until we can get in compliance. Issue #1157 Change-Id: Ie27be6ec6632b7786a1f9ebc32911ba9dcd42599

Git checks out files with native newlines, which is making eslint angry. Issue #1157 Issue #1228 Change-Id: If83adca5c206581c5fe1883a07c4d5c84a326663

This avoids line-length limits on Windows in the node module's pass-through shell script. The long list of files, combined with a node module's bin file, tripped the Windows command-line length limit of 8k. The transition to eslint, therefore, broke the Windows build. Issue #1157 Closes #1228 Change-Id: Ie57624efbbbfb4a27035e82ab12e788d18652ae3