Let's start this article with two axioms. One happens to be something from the book Sapiens and goes like so: "Human race was able to make such tremendous progress in the cognitive revolution because our language gave us the ability to convey ideas that don't exist in real life, ie. fiction. The second happens to be the fact that machine languages are far more inferior compared to human languages. This is because they fail to be as expressive as human languages.
Combining the two facts would easily help us come to the fact that to make general progress in the coding domain, we have to make the best use of the language at hand in order to pass as much information as we can to the folks who would be reading it after we give up ownership of it.
The next obvious question is, how the hell does linting play any role in improving the efficiency of knowledge transfer.
If the code doesn't feel like one cohesive piece of text then one needs to keep a lot of context in the back of their head while reading/inheriting codebases. The code has to feel as if it was written by a single person rather than a bunch of people, hence should follow a very opinionated set of rules. Thus linting helps in making the code a bit more predictable hence letting the reader focus on more complicated parts of the code.
Reasons aside, the JS ecosystem has a well-defined linting ecosystem but configuring it is something everyone ignores as most of the project scaffolds come pre-configured. But for power-users, it is an important thing to understand. Let's take a look.
So what exactly is ESLint? It happens to be an NPM package that can be executed in order to auto fix formatting and syntax errors. To add on top of it, the configuration file that it uses to do so doubles as a guide for smart IDEs to help you give warning and errors in real-time. Some IDEs also have installable plugins for ESLint that will let you run the formatting step from the IDE itself. But that is more of a brownie point.
The installation and setup guide can be found on the official page.
If you pay attention to the points mentioned at the starting of the official guide, it is said that rules are basically plugins in ESLint. This makes ESLint extremely powerful due to its extendability. Let's break it down feature by feature via the config structure.
After you set up eslint.{js/json/yaml} you'll start with writing rules. Rules are basically any of the listed constraints that you plan to use from the ESLint rulebook.
module.exports = {
rules : {
"semi": ["error", "always"],
}
}
A point to note is that semi rule has been picked up from the rulebook mentioned above, and thus we are free to list many more in this rule object.
Rules have to be explicitly turned on by making use of the rules object else ESLint will completely ignore our code.
This object basically tells ESLint which platform is your code targeted towards. For instance, it could be browser or node . Now if it were browser , we would want document and window object to be a global variable and using them without predefining them in scope should not be considered as an error by the linter. Hence, the purpose of env key is to basically let the some predefined global variables slip under the linter's radar. This is how we would use it if our code was supposed to run on browser as well as node.
module.exports = {
env: {
"browser": true,
"node": true
},
extends: ["eslint:recommended"],
rules : {}
}