Clean and consistent code across your entire team automatically (automagically)!
A code linter is a process that scans code to ensure that it is written in a way that matches a predetermined “code style”. It is generally applied when code is submitted to a repository and ready to be reviewed. For example, a code linter may validate that all code has the correct number of spaces or the appropriate number of line breaks between lines.
The code linter uses a list of predefined rules to determine if the code being “linted” matches up. This list of rules ensures that the code style is always respected regardless of the developer that submitted it. Generally, if your code does not meet the requirements it is flagged by the linter and is sent back to the developer to review and fix the errors that were flagged.
Code linters remove the cruft and formatting opinions of code in a repository. If you have a large number of contributors to a code base you absolutely want some consistency and predictability in how your code looks and is formatted. A linter is a great way to enforce that and can be built as a layer within your process. At Isovera, the code linting step happens before it reaches a human for formal code review. This means the reviewer can then focus their review on the logic of the code and not the formatting since the linting step has already taken place.
This process isn’t perfect, however. In fact, it puts a lot of responsibility on the contributing developer to make sure they are conforming to the standard that has been set by the code linter. This also assumes that the code linter has been configured correctly and a format style has been decided on, which in itself is a time consuming and very opinionated proposition. On top of all of this contributors and reviewers can choose to ignore the errors altogether causing an ugly series of warnings that all developers see during the build (I’ve seen it numerous times and may be guilty of it myself. Shhhh.).
It was time to break the cycle.
As you can imagine this step in the process can be a tedious, agonizing, and outright annoying to a developer. It’s necessary in the big picture of a project but slows down an issue that needs to get out the door fast. We want our code to be clean, consistent, and readable, but the more cycles of review the slower our output as a team is. I don’t know about you but I’m a human (mostly I think) and therefore I am prone to make mistakes. No matter how careful I am a machine is always going to faster and more accurate than I ever will be.
I was sure there had to be a better way. If a linter can determine I’m making all of these mistakes why can’t it just FIX those mistakes for me. I have spent too much time re-writing my code to appease my Linter Overlords. I needed a change, we all do.
Hello to a Prettier format.
Prettier is a code formatter that, when applied, will REWRITE your code to conform to a predetermined rule set (ie: Prettier style guide). It can be installed as a node package within a project or offers extensions in most of the popular code editors. This means that on supported files it will clean them so they are all formatted and consistent! Awesome!
Ok this is great! All we need to do now is get every developer to agree and install an extension in their code editor and voilà! We can always guarantee that this approach will happen every project every time right? Right?
Nope.
Back to square one.
All Hope is not lost.
More tools to the rescue!
Well since we obviously can’t predict what every developer installs or runs on a project, we need to come up with a solution that will automate this step for them. For this we use can use two tools: Husky, and Pretty-quick.
Husky is a tool that allows us a scriptable way to catch a commit right at the point of submission. So as the developer goes to submit code to the codebase, Husky can run a series of processes before that code hits the repository. Pretty-quick is another helpful tool that will run Prettier on our changed files. By using this we can improve performance as we only want Prettier to run on any new files being submitted. Using these two tools together means that as long as the file type is supported by Prettier, each file will be formatted and cleaned up automatically! This process piggybacks every commit in the background so a developer may not even realize it’s running when they commit. It just happens, like magic (and who doesn’t love magic?).
This seems too easy to be true.
(It’s not!)
All this can be yours in 3 easy steps:
- First install the 3 packages.
npm i -D prettier husky pretty-quick"husky": { "hooks": { "pre-commit": "pretty-quick --staged" } },
- Celebrate.
The above example is performant, automatic, and significantly cuts down on the amount of linting errors we have seen. This means less code being is being kicked back to the developer which equals faster output for FREE. Although some may argue that you have less control over the opinions as Prettier boasts itself as an “opinionated code formatter”, in reality none of that is important to us. How the code is formatted is less important than IF the code is formatted. The ability to take the human aspect out of this step is huge win for less mistakes and more consistent code quality.
Less cycles, more consistency, faster output.
