I think half the purpose of linters is to make code uniform. By enforcing the same style guide on everyone (automatically), it's easier to read other people's code. So it's an advantage, even if the change suggested isn't inherently an improvement.

That said, I can't speak for eslint, but I myself feel that other linters have pretty good suggestions. With a fair number of exceptions, I think they're a net benefit, even when working alone.

M -- I'd agree with that given some of the options that are disabled by default -- but if that's the point why are they... well disabled by default?

Like brace-style... I disagree with what it does (I'm a "opening belongs on the line huffing opening it" type) but for forcing consistent style it's a good idea. Forcing uniform usage of tabs on indents, verifying that all indents are EITHER tabs or spaces with no mix-match, enforcing the use of curly brackets even when not needed I disagree with, but if that's the style a project is using you bloody well use it, and having a tool to check that is a good idea.

But that's all stuff disabled out of box, and instead pedantic nonsensical BULLSHIT like no-unexpected-multiline (making code HARDER to read), no-var forcing you to ONLY use the dumbass 'let' and 'const' (missing that all three might just exist separately for a reason), no-empty breaking conditional loop constructs, etc, etc... the stuff 'out of box' is just plain nonsense.

Or even the silly thing for making it complain about "Yoda" constructs (as if there's such a thing) when reversing the static before the dynamic can actually result in smaller gzipping of the output... which is why many minifiers will switch it around for you... nothing like having a tool tell you not to do something that another tool (that most everyone will use) will then go and flip it back around. Hurr-durr...

In that way it reeks to me of the same mentality where people have become so reliant on version control they no longer know how to communicate with team-members and project managers get to play farmville instead of doing their damned job. If used to enforce a style guide it just means nobody is reading or understanding the huffing style guide.

Kind of like how if people can't be bothered to use H1...H6 and HR properly to create their logical document structure, throwing pointlessly redundant and ultimately useless tags at it in the form of article, aside, header, footer, main, nav, and section isn't the answer! Don't even get me started on the microformat junkies 'special place' to yank their own cranks known as aria roles.

As a rule tools don't make up for incompetence, they only reinforce it.

Jason Knight I agree with you on the use of var const and let existing in your code for various reasons. I don't use eslint on some of my personal projects; most of the times that I've had to use eslint were for when I was working with a team. That said I just deleted and uninstalled eslint for the project in question as the none existent errors were becoming annoying and distracting. Some of the error flags were for errors that didn't even exist. I actually think linters are quite helpful, I've never had this problem while using eslint for server-side code, so maybe I could be missing something with the config file.