ESLinter is my JS Spirit Guide pt.1

6 min readDec 15, 2020

One of the greatest things I’ve done to advance my understanding of Javascript is to implement Airbnb’s ESLinter configuration file. I use this in combination with Prettier for consistency.

I found the best way to implement all these tools together in harmony is to use Paulo Ramos’s script:

 exec 3<&1;bash <&3 <(curl https://raw.githubusercontent.com/paulolramos/eslint-prettier-airbnb-react/master/eslint-prettier-config.sh 2> /dev/null)

The above script, when executed in the root of your project directory will install the npm packages for Prettier, ESLinter, and the Airbnb configuration for ESLinter.

What you will quickly find out if you have never used this strict configuration of the ESLinter is that many methods and functionalities built into JS are actually doing things under the hood that you may have not necessarily cared to know about (unless it’s something that directly affected a project you worked on or caused odd behavior that forced you into another technique). This configuration streamlines this process, preventing you from making those mistakes in the first place or ever again.

The added benefit here is that each of these guidelines also has an attached explanation for why it exists so you aren’t just blindly following rules.

Sometimes I write code for development purposes, like when I am practicing algorithm problems and such. In these cases, I will disable rules such as ‘no-console’ whose purpose is to prevent you from having console statements in your production code since console statements are generally used as a troubleshooting tool.

The format of their documents includes examples and also a section that goes over scenarios in where you might consider disabling a particular rule. Their documentation does mention that sometimes it is acceptable to use console statements in Node.js and in these cases you might want to disable this rule.

Here ESLint is highlighting line 31 as an error which reads:

“Expected an assignment or function call and instead saw an expression. Eslint no-unused-expressions”.

A ternary that increments or initializes an object value.

The ESLint docs read: “This rule aims to eliminate unused expressions which have no effect on the state of the program.”

The docs also show incorrect and correct examples for the default rule state. Further below, it shows examples specifically for using the ternary operator.

My ternary looks like the incorrect usage example they give showing an expression on the ternary. So I think I will go with a short-circuit instead.

The next squiggly looks like it’s under the unary operator in the for the statement.

The unary operator has a case of the squiggles.

The ESLint docs state the reason for flagging this is, “Because the unary ++ and — operators are subject to automatic semicolon insertion, differences in whitespace can change semantics of source code.” Basically, the function the unary operator performs differs depending on its location in relation to a value. Just with changes to the whitespace within a file, it could easily end up operating on the wrong value or variable without you knowing. Whether that’s from minifying, formatting, etc. In their examples, they just recommend using +=, -=, etc. to prevent this issue.

After applying that fix it looks like the linter is happy with our code.

Let’s try another.

Tests whether the chars of one string exist within the other in order.

First, we have squiggles under the var variable assignments. As you may have guessed, this is because, since ES6, we’ve been able to block scope our variables with let and const. This prevents us from declaring variables with a global scope which could lead to the unknown reassignment of those variables and subsequently, not actually knowing what data type is saved to that spot in memory.

This is a simple and common enough change where ESLint can actually change your var assignments appropriately to let or const for you automatically.

The next squiggle is line 53. The reason behind this one isn’t quite as obvious but still simple enough of a fix where we can do the auto-fix again.

Here’s what the docs have to say about it though. To sum up, they feel there should be spaces following comments to make them more readable. This really doesn’t have much impact on your code overall except to enforce consistency. This is one I would consider configuring to my own preferences.

Here’s what ‘isSubsequent’ looks like after making those adjustments.

While we’re here, why don’t we fix up one last algorithm?

Squiggles, sometimes known as the ‘red sea’.

This one has squiggles all over, the first of which is on line 9, ‘no-return-assign’.

They essentially say that it’s best practice to not make assignments in return statements because of the ambiguity between intention and error. When you see this, you don’t know if the author is trying to make a comparison and left out an equal sign, making the code an error, or if the assignment was the author's intent. They could have just as easily made the assignment prior and returned that variable and done away with the questions altogether.

Referring to the ESLint docs for this warning, I find an ‘incorrect’ example that looks a lot like how I wrote line 9 of ‘areThereDuplicates’. The example look like: const foo = (a, b) => a = b .

Their docs say that I can write it like: const foo = (a, b) => (a = b) but that solution doesn’t quite work for me so I’m considering a refactor to something that will make the algorithm a little bit more stylistically consistent anyways.

Well, ‘no-return-assign’ went away but we still have squiggles all over, let’s see what we have going on now.

When I see things like ‘regenerator-runtime’, I know it’s time to do some reading.

Learned about this warning has been incredibly informative. That’s the point of this article.

Ah geese, what have I gotten myself into now? I open the docs for both and they each lead me to the same page and upon checking the error I realize that they are each labeled ‘no-restricted-syntax’.

Reading the docs, they describe this rule as a way to easily disable certain features for a project. They go into detail about customizing the error message to explain why that has been done. That means, they identified these specific features and hand messages specifically for them. Knowing this, I can probably get away with another refactor here.

Object.values provide an array of that object's values. Then I just iterate across it.

I know solving some of these issues they bring up can be annoying and often even opinionated. They seem to have been created with a professional production environment in mind. This may not be your use case, a lot of the time it isn’t my use case either. I would highly recommend that whether or not you feel a certain rule is relevant to your use case, you look into the rule to be sure. Make and understand the corrections before you come up with the determination to use it or not. Seeking these answers, even if sometimes tough or time-consuming, has almost always been worth it for me. I especially enjoy when it has to do with the way Javascript works underneath the hood, like with the warnings thrown when I used for…in .

I hope this was a help to you. If you find any errors or have any recommendations I would love to hear about them. Feel free to connect with me on LinkedIn or to leave a comment.