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.
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.
Top comments (12)
I had to admit, JS is the language I never had the patience and time to setup a linter. After a few hours I have to disable it because of numerous problems (from babel to IDE to a different plugin or option), including the fact that most NPM packages throw warnings and errors basically crippling my linter and bash. And ofc each person has its own JS style because why not. But wait, where do you put the settings? Oh here, so 10 more minutes wasted.
There are so many settings, linters, popular configs, each of them has to come trough a different NPM and each IDE has 20 settings on how to link them, and everything is soooo complicated. In the end I get hundred of warnings from 3rd party plugins, and the guess what, you have to add other options in the config to ignore those folders. God forbid to to output a message in your nodeJS app to log, the mighty linter will think you forgot it, because guess what, devs are debuging JS apps with console.log.
Sorry but life is too short. I got spoiled by Go where most of the linting is done by the compiler and builtin tools.
PS: sorry for my rant, your article is great
Hello Adrian, yeah I totally get how you feel about NPM third party warnings and those configuration settings. Makes you want to pull your hair out!!
LMAO totally agreed! JS 3rd party is too complicated
I really enjoyed the format of this article, thanks for sharing. The back-and-forth "conversational" style really helps draw out the benefits of using a linter.
I second that, good and succinct, explained well. Also a fan of ESLint + prettier.
Thanks Peter! It's actually inspired by a real talk I had with a colleague.. I think why not make a post out of it haha
»Oh, and if you are lazy like me, you are pretty-quick to make your code look prettier« ;)
Definitely for formatting.. You'd still need error checking and fix though
Is it me or I see nothing wrong about the
forloop? I even executed it on my browser javascript console and it displays 5 times "The number is [x]"Ah my bad! I've changed the code so please be ready to kill your browser console before trying again. Thanks for pointing it out :)
I suggest to use prettier for formatting and eslint for error detection, like unused varaibles etc. Check out this eslint config npmjs.com/package/eslint-config-re...
Yeah that seems to be the best of both worlds these days. ESLint can also fix errors using --fix option