Enter ESLint. In my downtime, I was curious to see what kind of an endeavor linting this application would be like. So, I set us up with an ESLint config (one that our organization uses) and ran the necessary command…

My brain hurt.

When running the command line utility, a flag called “ — fix” can be appended to automatically fix smaller issues with whitespace, single vs. double quotes, adding trailing commas, etc. After running the command, I sighed a sigh of relief:

Ok, not so bad.

So where do I go from there? My first reaction was to just start going file by file and fixing every error I found manually. It was not going to get done quickly, and while I fixed things, more and more code was getting into master, with the possibility of adding to this giant stack of errors. I needed buy-in from the team. I couldn’t just take this all on by myself.

My first step was to introduce the config into our codebase, but make it optional for engineers to have ESLint running on every file change. (That would be overwhelming for anyone, not just little perfectionist me.) What this did (besides get my opinionated foot in the door) was made it possible for me to run the linter against any file I wanted. And so I began to create PRs that linted single files, in an attempt to fight the good fight.

That first step helps a lot, but still does not prevent bug-ridden code from entering the codebase. All I could think was, “How can I make this a piecemeal process? I don’t want to create a gigantic PR of every single file being fixed.”

I took a cue from the previous team’s dream setup and researched pre-commit hooks. Aha! I could just create a pre-commit hook that linted that branch’s changed files. That way, every team member would be contributing to this effort without us having to set aside a large chunk of time to get it all done at once.

The pre-commit hook was rather simple to create. I set us up with Husky and found a very useful shell script (see brunops’s comment from May 6, 2015) for running ESLint against staged commits.

Going forward, we will not be able to commit to branches unless the changed files pass our linting standards. Of course, in my free time, I want to continue to lint files that aren’t being touched, because I am super eager to get our overall linting errors to a glorious zero.

I plan to occasionally check up on our team’s progress in this effort and once we have gotten all files’ linting errors down to zero, we will make the change to have our Webpack build constantly running ESLint. Whenever we make a change to a file, the linter will warn us of any issues along the way. At that point, we will have a much cleaner codebase, a consistent style, more up-to-date usage of React, and most importantly: we are guaranteed to have less bugs. If you are ever entering a team with legacy code and the option of incorporating a linter seems overwhelming, do not fear: it really is possible to do this thing piecemeal. It may take some time, but the benefits greatly outweigh foregoing the effort.