.eslintrc

/*******************************************************************************
* A Meteor Developer's ECMA 6th Edition ESLint Configuration
* by @iDoMeteor
*
* http://github.com/idometeor/meteor-style-skeleton/.eslint
*
* TL;DR
*
* This is more friendly than Meteor's config.. mostly.  Not always though. :)
* Check Github/README.md for quick usage instructions.
*
* Description
*
* Meteor upholds a high standard for coding, so do I, and so should you.
* With that goal in mind, I set every option in this file with intent.  It
* may provide you with a fair amount of frustration if you are new to linting
* tools.
*
* This is intended to be integrated into your editor (along with .editorconfig)
* in such a way as to allow you to use it continually.  If you drop it on a
* large, existing code base that may be... lax in coding standards, expect to
* get an enormous amount of reports.
*
* However, if you already have smart ECMA coding style, then you will most
* likely appreciate the learning experience / tightening up of your style.
*
* Meter and ECMA are both intended to be flexible.  This file allows for that
* flexibility where appropriate, but also has sane protections for actual
* poor programming methodology.  Hopefully it will allow enough flexibility
* to still take advantage of the fun parts of the language.
*
* In general, this configuration in tandem with my .jscsrc should provide
* one of the best programmatic ways to ensure that your Meteor code is as
* near to being inline with the MDG Style Guide as is practical from an
* automated tool.
*
* Caveats:
*
* I allow (and prefer, unless Sciencing) ==.  The Abstract Equality
* Comparison Algorithm is no more "obscure (src: ESLint)" than is the
* Strict Equality Comparison Algorithm.  Actually, it comes first not only
* in this paragraph, but also in the ECMA specification (11.9.3 vs 11.9.6).
*
* The standard convention comes from the same old-school origin as using !!.
* Namely, poor programming practices and ECMA implementations from the past.
* There are distinct advantages to using == in non-precision (read
* non-mission-critical) contexts.  I'll leave that dark magic up to you to
* discover.
*
* Point is, you should probably be statically typing if you are that are that
* concerned about precision, or not concerned about this level of semantics if
* your ability to keep your types straight is ... still developing.
*
* That being said, I throw warnings on (x == null) || (x != null). :p
*
* This is not for niave Javascripters, you should be able to
* grok what this is going to do for you or use eslint --init at the command
* line and go from there.
*
* I use object literals instead of switch, as one should.  However, once in
* a while, a switch w/fallthrough and/or no default is actually highly useful.
* For instance, Twiefbot uses micro-switches in the natural language
* processing.  Therefore, they are allowed, but will throw warnings.  That
* means that, while you should not do it, if you really know what you're doing
* then go for it.
*
* Contributing:
*    I welcome pull requests!
*
* ****************************************************************************/

{
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module",
    "ecmaFeatures": {
      "arrowFunctions": true,
      "blockBindings": true,
      "classes": true,
      "defaultParams": true,
      "destructuring": true,
      "experimentalObjectRestSpread": true,
      "forOf": true,
      "generators": true,
      "jsx": true,
      "modules": true,
      "objectLiteralComputedProperties": true,
      "objectLiteralDuplicateProperties": false,
      "objectLiteralShorthandMethods": true,
      "objectLiteralShorthandProperties": true,
      "regexYFlag": true,
      "regexUFlag": true,
      "spread": true,
      "superInFunctions": true,
      "templateStrings": true,
    },
  },
  "env": {
    "browser": true,
    "es6": true,
    "jasmine": true,
    "jquery": true,
    "meteor": true,
    "mocha": true,
    "mongo": true,
    "node": true,
    "phantomjs": true,
  },

  "rules": {

    /**
    * General
    */

    // This will throw warnings anywhere 'use strict' occurs, which is good.
    "strict": [2, "never"],
    // This wants you to migrate to using let & const instead of var for locals
    "no-var": 0, // Best to start migrating now tho :)


    /**
    * Allowances
    */

    "block-scoped-var": 0,
    "dot-notation": [1, {"allowKeywords": true}],      // Dynamic keys ftw, especially ES6 style
    "eqeqeq": 0,            // This contradicts MDG Style Guide, which prolly is [2, "allow-null"]
    "no-console": 0,
    "no-param-reassign": 0, // I do it, but don't use arguments meta-var much
    "no-reserved-keys": 0,  // 3rd edition is dead, no worries here
    "no-undef": 0,          // Super annoying in Meteor code, lol
    "radix": 0,             // If you screw up your numbers, your own fault
    "yoda": 0,              // I yoda, everyone should
    "vars-on-top": 0,       // Seriously, hoist your vars. But sometimes I like to validate
    // first.  Just don't bury (or not delcare!) your declarations.

    /**
    * Errors
    */

    "curly": [2, "multi-line"],
    "no-cond-assign": [2, "always"],  // This is why you should yoda :p
    "no-constant-condition": 2,
    "no-dupe-keys": 2,
    "no-duplicate-case": 2,
    "no-else-return": 2,
    "no-empty": 2,                    // Empties can break Meteor in Templates.*
    "no-eq-null": 2,
    "no-eval": 2,
    "no-ex-assign": 2,
    "no-extend-native": 2,
    "no-extra-bind": 2,
    "no-extra-semi": 2,
    "no-func-assign": 2,
    "no-implied-eval": 2,
    "no-inner-declarations": 2,
    "no-invalid-regexp": 2,
    "no-irregular-whitespace": 2,
    "no-lone-blocks": 2,
    "no-loop-func": 2,
    "no-native-reassign": 2,
    "no-new": 2,
    "no-new-func": 2,
    "no-new-wrappers": 2,
    "no-obj-calls": 2,
    "no-octal": 2,
    "no-octal-escape": 2,
    "no-proto": 2,
    "no-redeclare": 2,
    "no-return-assign": 2,
    "no-script-url": 2,     // No need for these in Meteor!
    "no-self-compare": 2,
    "no-sequences": 2,      // I hate that!
    "no-shadow": [1, {"hoist": "functions"}],
    "no-sparse-arrays": 2,
    "no-throw-literal": 2,  // Hopefully this lets Meteor.Error pass
    "no-unreachable": 2,
    "no-with": 2,
    "use-isnan": 2,
    "wrap-iife": [2, "any"],


    /**
    * Warnings
    */

    "comma-dangle": [1, "always-multiline"],
    "consistent-return": 1,
    "default-case": 1,          // *If* you happen to use a switch, maybe you don't want a default
    "guard-for-in": 1,
    "max-len": [1, 100, 4],      // Warn if over 100, tabs expand to 4 (should use spaces anyway)
    "no-alert": 1,
    "no-caller": 1,             // Should be 2, but there is some code out there... ;>
    "no-debugger": 1,
    "no-extra-boolean-cast": 1,   // I should give it a 2 but being nice!! (Sasha uses them)
    //                                     ^punny, eh! :D
    "no-fallthrough": 1,          // *If* you happen to.. it shouldn't be often.
    "no-floating-decimal": 1,     // Should be 2, but I bet lots of you...
    "no-multi-spaces": 0,         // I like pretty
    "no-multi-str": 1,            // Should be 2, I'm being nice :>
    "no-shadow-restricted-names": 2,
    "no-unused-vars": [1, {
      "vars": "local",
      "args": "none"
      }],
      "no-use-before-define": 2,

      /**
      * Style
      */
      "brace-style": [2,
        "1tbs", {
          "allowSingleLine": true
          }],
          "camelcase": [2, {
            "properties": "always"
            }],
            "comma-spacing": [2, {
              "before": false,
              "after": true
              }],
              "comma-style": [2, "last"],
              "eol-last": 0,
              "func-names": 0,      // Something I'm trying to eliminate, anonymous functions
              "func-style": 0,      // Flexibility ftw
              "indent": [2, 2, {"SwitchCase": 1}],
              "key-spacing": [2, {
                "afterColon": true,
                "align": "value",
                "beforeColon": false,
                }], // 'prop': x, extra spacing allowed if lining up blocks
                "linebreak-style": [
                  2,
                  "unix"
                ],
                "new-cap": 2,
                "no-multiple-empty-lines": 0,
                "no-nested-ternary": 0,     // I <3 them, as long as they are clean & clear
                "no-new-object": 2,         // There are good reasons not to
                "no-array-constructor": 2,  // There are good reasons not to
                "no-spaced-func": 2,        // Nice addition!
                "no-trailing-spaces": 2,
                "no-underscore-dangle": 0,
                "one-var": [2, "never"],
                "padded-blocks": [0, "always"],
                "quotes": [
                  2, "single", "avoid-escape"
                ],
                "semi": [2, "always"],
                "semi-spacing": [2, {
                  "before": false,
                  "after": true
                  }],
                  "keyword-spacing": [2, {"before": false, "after": true, "overrides": {
                    "if": {"after": false},
                    "for": {"after": false},
                    "while": {"after": false},
                    "from": {"before": true}
                    }}],
                    "space-before-blocks": 2,
                    "space-before-function-paren": [2, "always"],
                    "space-infix-ops": 2,
                    "spaced-comment": [2, "never"],
                  }
                }