Full download instructions can be found here. After installation is complete, you should now see a new script in your package.json file, like this:
If you now run:
The linter will be triggered and it will tell you if your code passes the linting process, simple!
What Happens If I Forget To Run the Linter?
Now we have a way to tell the compiler to test if our code meets our coding linting standards, however, this approach has a big downside. You have to remember to run the ESLint command manually before you commit your code. In my way of seeing the world, anything you have to do manually, your deployment process is a bug and you should be automated.
The easy way to fix this problem is to get GIT/NPM to trigger ESLint before you are allowed to commit any code. If you want to consistently run a linter on your project, you need it to be run automatically before you even commit your code into source control. Having your code quickly linted before every commit and then being forced to fix the errors before you commit will ensure a higher-quality code base. Like doing commits, or, even releasing a website working in little increments often is a lot more simple and efficient, than doing a big bang limiting fix once every few months.
How Can I Add A Pre-hook?
One way to trigger ESLint before a commit is to add a GIT pre-hook. If you are new to creating a pre-hook look -assuming you use GIT and it's installed on your project - look inside the '.git/hooks' folder. In here you will see a number of disabled GIT scripts you can enable and use. One approach to enable linting is to enable the pre-commit hook and add some code inside it.
Personally, I don't really like putting scripts here. The majority of developers only have a basic grasp of GIT on the command-line and how its folder structure works. When you use GIT to run a pre-hook you end up with 'magic' in your solution that no one in the team really understands.
When it comes to enabling linting within a project, my preference is to tackle the problem in the same way we run any useful project script, do the work within our package.json file. As you will already have scripts and config items within your package.json file that people on the team use, adding your pre-hook scripts in here will make your project more consistent for the team.
As you would guess several packages already exist to allow you to do this:
pre-commit. Pre-commit allows you to run a script from your package.json before your GIT commit will be completed. To install pre-commit, you can run:
Full-instructions can be found in pre-commit. After installing pre-commit, you can configure your package.json like so:
Every-time you make a GIT commit now every JS file in your project will be checked and linted. If any of those files fail your linting rules, then you will not be allowed to commit your changes until you have fixed everything.
Pre-commit is great on small projects. What happens if your solution contains 10,000 .js files. Run a full lint on every commit will make your development process very slow and cause a lot of frustrations as your project grows?
On big projects, you will only want your linting to be run against the specific files you want to commit. This can be done with another package called, lint-staged.
This command will install lint-staged and another package called husky. After installing lint-staged, you should update your package.JSON to look similar to this:
That's it, you have now added linting to run automatically on your project!