When I started learning Javascript, I was encouraged to use ESLint, but I had no idea what it was... and I had no idea that it wasn't working until my instructor pointed out that my linter wasn't catching any of my errors. I reinstalled the extension in VS Code and suddenly I was amazed. It is a node-npm based tool so you will need to install node in order to run ESLint. Then you can install ESLint globally by finding the extension in VSCode or entering the command in the terminal

npm install -g eslint

What is a linter? The name is very telling. A linter is a helpful debugging tool that sifts through your code looking for patterns of behavior. If it catches an irregularity, it will alert you with the type of error and its location in the document. Not all errors will break your code, but ESLint is there to tell you when any appear and help you to follow best practices.

Before ESLint came around, a common way to check code for these kinds of errors was by copying the code and pasting it into a website like JSLint, but now we can do it seamlessly inside of the text editor.

Nothing comes loaded by default, but they do have a package of recommended rules that can be easily added to get you started. You can create a new eslintrc.js file, and add the recommended rules inside or build your own set. If you take a look at the documentation of ESLint's rules, the checkmark denotes all of the rules included in that package.

module.exports = {
  "extends": "eslint:recommended"
}

Each rule in the documentation has tips for usage and reasons why you may or may not want to use it. You can add more rules or override recommended rules, using a value of 0 to turn the rule off, 1 to show a warning, and 2 to show an error.

module.exports = {
  "extends": "eslint:recommended",
  env: {
    "es6": true
  },
  "rules": {
    "no-var": 1
  }
}

Above, you can see an example of adding an ES6 environment for the use of arrow functions and other exciting ES6 features. There's also an added no-var rule that is set to show a warning. Now if you were to try to declare a variable with the keyword var, you can trust that ESLint will catch it with a not-so-subtle hint just like those squiggly lines under misspelled words on all of the papers you stayed up late to write over the years.

In VSCode, The error will appear in the problems panel, showing its location in the file. You can click the error in the panel and it will bring you to the actual line of code where you can inspect it and make any changes. It's simple and straightforward but who wants to sift through errors like trailing white space or missing semi-colons? To increase efficiency, you can add auto-fix in your global settings to take care of small errors and cut down on time spent searching for each individual error. To do this, navigate to your settings.json at Code > Preferences > Settings (Command + ,) and type eslint into the search bar. This is where you can add an auto-fix.

"editor.codeActionsOnSave": {
        "source.fixAll.eslint": true,
    }

If it catches a larger error like a declared variable that is never used, ESLint doesn't know what you would like to do with that variable so it will remain until you fix it. If it finds an error that can't be auto-fixed, you can check the "problems" tab in VS Code and it will give you a short explanation of the error found as well as where to look for it in your file. Double-clicking on the error in the problems tab will bring you directly to the line where the error exists.

In the beginning, we installed the linter globally but in the short example above, we created a file in the root folder of the project. Because different environments have different rules, this makes it easy to pinpoint errors based on that specific environment. It also makes it easier to transition files when working with a team. So you've made your ideal configurations, and you're feeling pretty great about it. Your files are wonderfully clean. Then one of your teammates makes some changes, and when you pull the new file, your linter finds some errors to clean up. The beauty of using ESLint in your project vs. globally is that you can share rules with your teammates so you all have the same workspace. If you don't create a new set of rules in the project's root folder, it will just fall back to the global settings.

As a new developer, ESLint has been very helpful as a guide to learning best practices. Because the errors are so apparent, it's easy to see how to properly form your code and make less errors as you get more practice.