pull updates from es20xx

[UltCombo]

Here are the initial ESLint rules posted by @jaydson, cleaned up a bit (not showing the rules which are enabled by default):

{
   "no-reserved-keys": 2,
   "block-scoped-var": 2,
   "curly": 2,
   "default-case": 2,
   "no-else-return": 2,
   "no-param-reassign": 2,
   "indent": [2, 4],
   "brace-style": 2,
   "comma-style": 2,
   "no-multiple-empty-lines": [2, { "max": 2 }],
   "quotes": [2, "single"],
   "spaced-line-comment": 2
}

Note: @jaydson has not specified the max option for the no-multiple-empty-lines rule, I've assumed 2 for the time being. Feel free to edit this message if it is wrong.

Rules to discuss

• [x] no-reserved-keys: this rule is aimed at ES3 reserved keys, and ESLint has this rule disabled by default. Seeing as we target the most recent (and future) editions of ECMAScript, we shouldn't have to care about ES3 compatibility IMO. Also, seeing as our code is compiled with Babel, even if we wanted ES3 compatibility, this is something that the compiler's code generator should handle instead of adding hacks to our source code. So can we disable this rule?
• [x] strict: by default this rule requires all code to have explicit "use strict";. Seeing as all our code is all in ES2015 modules which are implicitly strict, I believe we should set this rule to [2, 'never']. Is this change ok?

... More to come.

[UltCombo]

After we settle the rules, we need to start fixing the code to follow the rules -- the build is failing because our code is not passing the linting at the moment.

[jaydson]

I think no-reserved-keys is more like a best-practice rather then ES3 compatibility, but we can keep it disabled.

strict: by default this rule requires all code to have explicit "use strict";. Seeing as all our code is all in ES2015 modules which are implicitly strict, I believe we should set this rule to [2, 'never']. Is this change ok?

:+1:

[UltCombo]

@jaydson quote from the no-reserved-keys documentation:

Rule Details

This rule is aimed at eliminating the use of ECMAScript 3 keywords and reserved words as object literal keys. As such, it warns whenever an object key would throw an error in an ECMAScript 3 environment.

When Not to Use It

If your code is only going to be executed in an ECMAScript 5 or higher environment, then you can safely leave this rule off.

[UltCombo]

Of course, it would be a best practice if we needed to run our code directly in an ES3 environment. However, our code goes through a compiler (and front-end scripts may also go through a minifier). These tools parse our code into AST, transform it and regenerate the code. In this process, these tools may add/remove the quotes around ES3-reserved keywords, so in the end it doesn't matter checking this rule against our source code.

And of course, we are not targeting ES3 anyway.

[jaydson]

That's make sense.

[UltCombo]

I've temporarily disabled ESLint in the build task as we really need the new improved workflow.

[UltCombo]

We can continue to discuss the code style here, or perhaps it would be better to open a new issue. Anyway, there are higher priorities at the moment.