Consider additional rules for default eslint config

[jthomerson]

As a team we need to discuss and decide on the use of the following rules. They may have value for us, but could possibly lead to a lot of refactoring of existing code to bring it into compliance with these rules.

• func-names
• func-style
• valid-jsdoc
• newline-before-return
• newline-per-chained-call
• no-inline-comments
• object-property-newline
• operator-linebreak
• no-magic-numbers
• no-param-reassign
• no-mixed-requires

[jthomerson]

@jimjenkins5 gave this one to you. It's quite old, but worth looking at least at the ones I listed since we're making a 2.0 release. End goal should be to close this ticket with a list of those rules, and if we incorporated them, and if not, why.

[jimjenkins5]

The applicable rules have been added in #23. Here is a summary of our decisions.

• func-names
  • We decided not to use this rule. The primary reason to enable seems to be so that the function name appears in stack traces. However, we decided that making this a coding standard isn’t necessary for two reasons:
    • We will be using arrow functions often, and these have the same issue.
    • The case where we’d need to name a function that would otherwise be anonymous seems far more rare than the case where it’s not needed.
      • Instead of forcing developers to add names to ever anonymous function statement, we could just let developers add them as-needed.
      • e.g. in all of our Gruntfile.js files, we have module.exports = function(grunt) {.... To satisfy this rule, we’d need to add a name to that function, which is really unnecessary.
• func-style
  • We decided not to use this rule, since we see a definite use case for both styles of functions.
• valid-jsdoc
  • This rule is not ready for production. We found many false positives and TypeScript would need completely different set of rules
• newline-before-return
  • This rule is depricated, but we added padding-line-between-statements with a configuration to force a newline before return.
• newline-per-chained-call
  • We are using our silvermine/fluent-chaining rule to handle our linting of chained calls. This rule was not enabled.
• no-inline-comments
  • We use inline comments all the time and like them. We did not enable this rule.
• object-property-newline
  • We added this with the option allowAllPropertiesOnSameLine. This is what we enforce in code reviews anyway.
    • Turning it on without that option would have been problematic because of our no-multiline-var-declarations rule. We would never be able to declare and initialize objects at the same time.
• operator-linebreak
  • We decided to enforce the after option here.
• no-magic-numbers
  • Although we don't like magic numbers, we decided to enforce them in code reviews where necessary. Linting magic numbers can be problematic if you want to do something like:
    • setTimeout(func, 1);
    • let inOneHour = Date.now() + (60 * 60 * 1000);
• no-param-reassign
  • This was not enabled because it prevents some of our use cases with reassigning memo in _.reduce.
• no-mixed-requires
  • This is not compatible with the one-var rule.