eslint new rules in 0.24.0 for ES5 mode

[andrewdeandrade]

There are a bunch of new rules in eslint 0.24.0. This thread is to evaluate which rules we'll enable for the next major release.

Here are the rules I identified as candidates for inclusion as an error:

• no-catch-shadow (probably a noop since there was already a no-shadow rule)
• no-continue
• no-div-regex
• no-else-return
• no-eq-null (probably a noop since we already enforce strict equality)
• no-extra-parens
• no-inline-comments (was already in lint-trap)
• no-mixed-requires (probably a noop since we do one var per line)
• no-throw-literal (long overdue, you should always generate an error object with a stack trace)
• no-unexpected-multiline
• no-unneeded-ternary
• array-bracket-spacing (was already in lint trap)
• block-scoped-var
• computed-property-spacing
• dot-location
• func-style - this rule I am unsure about and want to try out because it seems like this isn't a 100% rule and it looks like it allows function expressions in many cases where you really only want a function expression (like assigning a function expression to a property on this in the constructor or assigning prototype props to function expressions). Because of this, I want to see how this actually works in practice.
• newline-after-var
• object-curly-spacing (was already in lint-trap)
• operator-linebreak
• quote-props - This one is turned on with the configuration "as-needed". I'm curious to get feedback on whether or not this is useful or problematic. Hard to tell without seeing how it actually works in the wild.
• sort-vars - Given that we require one var per line, this one probably is a noop. However there is another rule, one-var which has an "uninitialized" and "initialized" option which is interesting that would make this rule relevant.
• space-before-function-paren - this one should be a noop because I believe this is already enforced by some other rule we already have turned on. This was already rule in lint-trap.
• spaced-comment - I need feedback from people on this one when it is used in practice. Most likely this is a useful rule, but will need to have the "exceptions" and "markers" options modified based on cases where it may not work.

The no-restricted-modules rules will be enabled for ES5 mode to disallow underscore and lo-dash modules.

FWIW, ES5 mode mainly affect those writing reusable front end libraries and working with NodeJS projects.

@Raynos @lxe @mlmorg @johnmegahan @jcorbin @kriskowal

[Raynos]

Please open a PR for discussion instead of an issue.

[Raynos]

Talking about real code that we want to ship rather then ideas is more effective.

[andrewdeandrade]

Most of these are now in this PR: https://github.com/uber/standard/pull/24