Reduce Maintenance Efforts with ESLint

Building high-quality apps is challenging for many reasons. Each developer has a unique way of programming, software projects need constant maintenance, and maintenance becomes increasingly complex with the growing codebase, etc. 

Fortunately, there are many tools that help us write code that is more organized, consistent, and bug-free, linter being one of them. 

What Is a Linter? 

Linter is a powerful tool that analyzes source code to identify any potential problems. It ensures that the code stays healthy and consistent, irrespective of the developer writing the code. It defines a coding standard that further simplifies the process of reviewing and maintaining the code.  

Writing JavaScript apps can easily lead to errors since the language itself has very flexible syntax and is loosely typed. However, ESLint can be used as an effective tool to reduce the risk of errors.    

Keep Your JS Code Clean with ESLint. 

ESLint is a powerful tool for ensuring that your JavaScript code follows a consistent style and adheres to a set of predefined rules. It can help catch common mistakes, enforce best practices, and make your code more readable and maintainable. ESLint works by analyzing your code and reporting any issues it finds. These issues can range from simple style issues, like missing semicolons or unnecessary whitespace, to more complex problems, like variable shadowing or the use of undefined variables. 

Get started with ESLint! 

To get started, you must create a package.json and add ESLint as devDependency. ESLint is available to download from both npm and yarn: 

The next step is to add the initial configuration with some rules by running the following command:  

Here, you’ll see a series of questions that allow you to adjust the configuration file based on your preferences: 

• How would you like to use ESLint? 
• What type of modules does your project use? 
• Which framework does your project use? 
• Does your project use TypeScript? 
• Where does your code run? 
• How would you like to define a style for your project? 
• What format do you want your config file to be in? 

Based on the options selected, the ESLint CLI will create a .eslintrc configuration file in the root of your project.  
This file should contain some default settings. If you already have rules you want ESLint to enforce, you can replace some of the options in the configuration file. If you just want to use the built-in recommended rules, there are a number of predefined rule sets available, such as the popular eslint:recommended set. 

• extends – allows you to extend your configuration file from other configurations 
• rules – core building block of ESLint, used for configuring the rules 
• overrides – to disable rules for a group of files 
• plugins – set of ESLint rules related to the same subject 
• etc. 

5 beneficial ESLint rules: 

These are some of the ESLint configurations that can help improve your project:  

1. no-console – disallow the use of console 

It’s considered a best practice to avoid using these methods.  

Such messages are considered for debugging purposes and should be removed before pushing to production. 

2. curly– enforce consistent brace style for all control statements 

It’s allowed to omit the curly braces when  a block contains only one statement. However, it is considered a best practice never to omit curly braces because it reduces code clarity. 

3. no-unused-vars – disallow unused variables 

It is common that there are unused variables left somewhere in the code due to incomplete refactoring and should be removed. 

4. sort-imports – Enforce sorted import declarations within modules 

This rule is using a specific member syntax: 

// single - Import single member. 
import myMember from "my-module.js"; 
import {myOtherMember} from "my-other-module.js"; 
// multiple - Import multiple members. 
import {foo, bar} from "my-module.js"; 
// all - Import all members, where myModule contains all the exported bindings. 
import * as myModule from "my-module.js"; 

It checks all import declarations and verifies that all imports are first sorted by the used member syntax and then alphabetically by the first member or alias name. 

5. no-restricted-imports – Disallow specified modules when loaded by import 

It would help if you considered using this rule in these situations: 

• When you want to disallow large dependencies which could bloat your JavaScript bundle 

• After you define import alias, and you want to forbid the use of relative imports 

• Some modules provide similar or identical functionality; think lodash and underscore. Your project may have standardized on a module. You want to ensure that the other alternatives are not being used as this would unnecessarily bloat the project and provide a higher maintenance cost for two dependencies when one would suffice. 

The rules that we’ve covered are just a few of the ones provided by the ESLint tool. These changes may seem minor, but they will positively affect your progress in the long run.   

Conclusion 

Linters have become an essential part of software development in general, and ESLint specifically in frontend development. They drive your team to make better decisions, save time, and increase productivity.   

If you haven’t tried it already, I recommend you give it a go! 

About Author

Meet Kristina Tadic, an exceptional software engineer with a talent for developing responsive web applications and creating innovative software solutions. With over four years of experience, Kristina has honed her skills working on various exciting client projects, from business automation software to greenfield projects. Her impressive proficiency in multiple technologies has enabled her to excel in her field and create high-quality, cutting-edge solutions.