No offense bro, but to me, it seems ESLint isn’t a big deal. My production code has been running for 2 years without linting at all. Why should I use one now?
First, I’d like to say that it’s true. You can work with JavaScript without linting. In fact you can work with any programming language without linting at all. Every wrong syntax will trigger an error, and you’ll have to fix your code before putting it live. From my experience however, linters most useful function is that it makes the app look like it was written by one person. Every developer has their own style, and using ESLint means you have a written agreement about how your JavaScript code base should look like.
Okay, I understand that one. But code style alone isn’t enough to convince me..
Have you ever made a commit where you forgot to cleanup console.log() ? ESLint can catch those code and returns error.
Hey, now that you mention it, sometimes I do that..
Yeah, sometimes developers are exhausted from looking at their editor all day long. Small mistakes, but still need to be fixed nonetheless. Also, sometimes we forgot to delete unused import statements.
At one time I imported a React component that I needed for development, but by the time I’m done with the task, I have removed the component from use. The import statement was left in the file, which should’ve been deleted.
Whoops. Sometimes I did that too..
Whoopsie. Yes, ESLint will make you see those pesky unused variables or imports. Another useful thing about ESLint is that it can help you with stuff that’s hard to catch by running or looking at the code. Consider this example. Can you guess what’s wrong with the code?
for (i = 10; i >= 5; i++) {
console.log("The number is " + i );
}
Hmm.. What’s wrong with it?
Kinda hard to see, huh? Well, the increment value is moving in the wrong direction and causing infinite loop.
Ah my bad!
Rather than thinking about what’s wrong with the code, you can have ESLint tell you that the loop will never end. It can save some seconds.
LOL
Let’s see another example here:
if(username = "Douglas"){
// do something
}
That’s assignment operator there, not comparison.. Yeah, and when you run the code JavaScript will just return true instead of yelling at you. Linters will disallow assignment operator in conditional statements where comparison operator is expected. Try one more here:
function updateUser(userId, userData, userId){
// do something
}
_LOL. Who wrote the same parameters in a function? _ Exhausted programmers sometimes do, mate. It’s better to conserve your mental energy and let linters warn you for this kind of errors. There are many similar error checks that ESLint can do for you. Check it out here Oh.. that’s neat.. still I’ve seen its documentation, seems I need to configure lots of stuff before I used it.
Well, you do configure Gulp or Webpack for your project all the time, don’t you? ESLint configuration isn’t that hard to get. If you’re really that lazy though, you can just use its shareable config which you can use freely.
Like boilerplate rules, huh? Yes, but don’t just set it and then forget! You have to see if the rule make sense for the project. As an example, there is ES Style Guide by Google here. Make sure you see its documentation first.
Sigh.. is there any way I can just set and forget? Another configuration to maintain is burdensome.
… Well, there is an initiative to make a universal rule of high quality JavaScript code that you can just install and run without configuring anything at all. It’s called Standard. The rules laid out in Standard are fixed and contributors debate on the issue section of the repo for the rules.
Awesome! I’m gonna try that!
If you decided to use it, there’s also text editor plugins you can use.
Alright. One less configuration to think about!
You know what’s funny? What? Somehow I think many developers do agree with you on ESLint configuration being a burden. Standard managed to snag the first place in Github clean code linters collection.
Well, not all developers are the same. Most definitely don’t love the idea of having to configure everything. Except you, maybe.
Maybe… 🤓 Anyway, don’t forget to add a git hook so that the linter is always run before a commit.
