AngularJS and ESLint Airbnb Style Guidelines: Some Rules are Meant to be Broken

In a perfect world — matter is governed by the laws of physics, people are governed by the laws of their municipality and country, and javascript is governed by a linter. And, if that world is UNAPOLOGETICALLY, PRISTINELY perfect, that linter is probably ESLint set to Airbnb’s style guidelines.

I like my Linters just like my Coffee: Strong.

Don’t get me wrong, I can certainly see the need for a strong linter — and ESLint provides me the options to do just that. It was designed to let developers make their own rules about their code, and make certain any person using their linting utility would be alerted to a trailing slash, an extra line, a var instead of a const — before even executing a line. Mistakes are corrected WELL before employers, teammates, or teachers can see how inanely sloppy their code may be. This thing is a god-send!

Or so I thought. If you’ve ever used Airbnb’s style-guide, you know that a not too much can cause your innocent code to be stricken with red lines. Last week, my teammates and I started building a pet-locating app in AngularJS with ESLint (Airbnb style-guide). We didn’t have to write half a line of code for this thing to light up like a Christmas tree. What did we do wrong?

Not too much. Some Airbnb rules compliant with other languages and frameworks are just NOT compliant with some versions of AngularJS 100%. For instance, you can easily head down a version-chasing rabbit-hole, installing and uninstalling packages left and right, breaking 15 things to save 1 line of code from the ‘red underline of death’ (as opposed to the ‘green underline of death’, which is not that bad and reserved for optional linting errors like console logs). In some cases, it would be like writing sub-par code just to appease linting rules. Even though there are AngularJS linters used precisely for working with AngularJS-specific rules, they may not be as stringent or as all-encompassing as the ones used for the Airbnb style-guide.

Some Rules are Made to be Broken

The cool thing about ESLint is that you can customize any rule you see fit, depending on available options for that rule (or just turning it off altogether by setting it to “off” or “0”). Perhaps you’d like to change the rule temporarily JUST for that file, or for the entire app — it allows for that too.

Special Rule Configurations I use for AngularJS

What kind of rules would we want to change or turn off when it comes to the AngularJS framework? Here are a few rules we might configure in our .eslintrc file:

(Note: Erring on the side of caution, I’d suggest researching all rules heavily prior to deciding to configure .eslintrc)

• require or disallow trailing commas (comma-dangle)

“comma-dangle”: [“error”, {
     “arrays”: “only-multiline”,
     “objects”: “always-multiline”,
     “imports”: “always-multiline”,
     “exports”: “always-multiline”,
     “functions”: “ignore”
     }],

• "always-multiline" REQUIRES trailing commas when the last element is in a DIFFERENT line than the closing bracket or brace and DISALLOWS trailing commas when the last element or property is on the SAME line as the closing bracket or brace.
• "only-multiline" allows (but does NOT require) trailing commas in the same instances provided for ‘always-multiline’. Here, we are assigning this option to arrays.
• "func-names": 0 turns off the rule that states every anonymous function be named. That means, prior to turning off this rule, every controller, every directive, every factory, etc., had two names, essentially: The one used for injecting into other directives and controllers, and one for its anonymous function.
• "prefer-arrow-callback": 0 turns off the rule that states every callback make use of ES6 arrow functions. Due to some this-binding issues in building controller elements without using the keyword $scope, it’s safer to use ‘this’ when the ‘function’ keyword is present.
• "no-param-reassgn": 0 turns off the rule dictating no function parameters be reassigned within the function bounds. It aims to prevent unintended behavior caused by possible side-effects.

“no-use-before-define”: [“error”, { “functions”: false, “classes”: true }]

• ^Just like it sounds, the linter will throw an error when variables are used before they are defined in the code. Here, I’ve set options for ‘functions’ and ‘classes’. The linter will ignore references to functions before their declaration when ‘functions’ is set to false. When ‘classes’ is set to ‘true’, the linter alerts whenever it finds a reference to a class before its declaration, which is the default setting.

“settings”: { “angular”: 1 }

• ^If you’ve noticed, the word ‘angular’ throws up an error from the start without any other manipulation of rules. Throw an ‘angular’ setting in your config file (while setting ‘angular’ to ‘true’ in ‘globals’ as well) to amend this.

“wrap-iife”: [“error”, “inside”],

• ^Immediately-Invoked-Function-Expressions must always be wrapped in parentheses in this case, with the ‘inside’ option referring to the function expression specifically.

“no-underscore-dangle”: 0

• ^This one turns off the warning for final, ‘dangling’ underscores used at the end of variable names with out specifically requiring ‘underscore’

Apply these rules are you see fit for strict, but not-too-strict handling of errors and warnings in your AngularJS code. That being said, PLEASE check out the docs before changing any rule without prior research.

Helpful Resources

List of available rules

Fine-Tuning AirBnB's ESLint Config