Frustrated With JavaScript Linters?
We feel you. Having to comply to certain rules that JavaScript linters enforce can be frustrating. But before we suggest ways to resolve your frustrations, let’s understand why we need linting. JavaScript linters, such as ESLint, are code quality tools that scan JavaScript code and return warnings and error messages based on certain rules. Those rules are stricter than the ones defined by the ECMAScript JavaScript standard, which can be a major cause for frustration: Why does that linter throw a warning despite it is working in my browser? Whyyy? #rage
Here are two reasons why we use linters:
- To avoid bugs. Even if a feature works while it’s implemented initially, certain coding habits can cause issues in the long run, when the site scales, when other features cause conflicts, or when the feature is tested on a different device.
- To ensure consistency. Most of our implementations require multiple developers. Even more important, most of our implementations are the groundwork for sites that will potentially be extended and maintained by dozens or hundreds of developers. So it’s our responsibility to do it right – right from the beginning. Moreover, having consistent rules across projects makes it easier and faster for our developers to support different projects.
Unless we’re on a project or with a client that has (company-wide) linting rules defined already, we currently start with rather broad rules that only ensure basic needs. However, we see the need for stricter rules, especially for projects with fast-paced development sprints where time for code reviews and revisions is scarce. Strict rules are also common in companies à la Airbnb and Dropbox.
In conclusion, you can’t go wrong by embracing the value of linting, and by learning how to deal with it. If you encounter linting warnings or errors, try this:
1. Paste the error message thrown by your linter into a Google search. A quick search on Google is usually all it takes to get to a straightforward answer on StackOverflow or alike. Searching for a solution via Google might seem obvious to you, but it’s not the natural first step for everyone. Of course, it can be fun to figure out a solution yourself – without asking Google for it. Most of the time, though, it’s worth to move on quickly and learn from someone else’s solution.
2. Check the documentation of your linter. For example, ESLint and Stylelint provide comprehensive overviews with all their rules, including examples on how to follow and not to follow a rule. Below is an example for ESLint’s “no-use-before-define” rule.
3. Discuss the linting issue with a more experienced developer and fix your code, or take ownership and adjust the rules for everyone. Whoever set up a rule had a reason for it, and it’s critical to understand the reasoning before blaming a rule. People are more responsive and willing to help than you think they are. We’re all on the same field.
