After installation is complete, you should now see a new script in your
package.json scripts section, 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 check if our code meets the 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 flawed. Stuff like this needs to be automated or people will forget to run it.
The easy way to fix this problem is to force ESLint to run before anyone on the team is allowed to commit any code. Having the code linted and forcing the team to fix the errors before committing will ensure a higher-quality code base. A commonly agreed development practice when working on a project is that small, frequent commits will result in fewer and less impactful merge issues when committing. The same is true for linting. Frequently making small fixes is much easier to manage than leaving the process until the end of the project. This is why adding linitng to your daily development workflow will be the more efficient approach to adopt. How do we make this happen?
How Can I Add A Pre-hook?
One way to trigger ESLint to run before a developer is allowed to push a commit to
origin is to add a GIT pre-hook. If you are new to GIT pre-hooks and know nothing about them, I have a challenge for you. Open up any project that uses GIT on your machine and look inside the '.git/hooks' folder. Within this folder, 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 I have worked with sadly only have a basic grasp of GIT on the command-line (these are C# developers mainly!) and how its folder structure works. When you use a GITpre-hook to run the linter you end up with 'magic' in your solution that no one in the team really understands. this is why I favour a simpler solution.
When it comes to enabling linting within a project, my preference is to tackle the problem in a consistent way. It is much simpler to perform the work within our
package.json file. As you will already have most of your project config scripts located within
package.json it makes more sense IMHO to add the lining rules here as well. Adding your pre-hook scripts in here will make your project more consistent for the team. As you could probably guess, there are several packages that already exist that allows us to do this:
The first option is 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 this command (full-instructions can be found here) :
pre-commit, you can configure
package.json like so:
pre-commit installed, every time that you make a GIT commit, every JS file in your project will be checked and ESlint with inspecting it. If any of those files fail to adhere to the linting rules, then you will not be allowed to commit your changes until you have fixed everything.
'pre-commit' is great to use on smaller projects. What happens if your solution contains 100,000 .js files. Checking every file on every commit will make your development process very slow and cause a lot of frustrations, how then to solve this challenge? 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.
lint-stage will only lint files within your commits staged files. This makes your development workflow a lot quicker while still ensuring your code adheres to your project's quality gates. If you want to perform a lint against everything, you can do that in your CI/CD pipeline instead before a feature is merged into one of your main branches (depending on your branching strategy). You can install
lint-stage using this command:
lint-staged will also install a package called husky.
husky gives your project native Git hook abilities. With these two things, their final step is to update
package.json. This look like this:
That's it, you have now added linting to run automatically on your project! Happy Coding 🤘