If you are new to Javascript and want to increase the quality within your codebase, then adding a linting tool within your project is a good idea. As humans, we are prone to making mistakes while coding. Typos, forgetting to remove unused references, forgetting to add the ';' at the end of a line, not adding the correct whitespace, the list could go on and on. Compilers are great for spotting these types of issues. This is what linting is all about. In this tutorial, I'll cover all of the steps that you will need to follow in order to enable linting within your Javascript project. Sounds good? Read on.
ESLint
When it comes to Javascript and linting, the go-to tool to use is ESLint. ESLint is a pluggable and configurable linter tool for identifying and flagging code formatting issues contained with a JavaScript project. You can enable ESLint for your project via NPM, using this command:
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:
pre-commit
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) :
After installing pre-commit, you can configure package.json like so:
With 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 Staged
Instead of running the linter against every Javascript file in your project, 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 🤘
