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”.
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 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.
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?
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.
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.
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.