Enhancing Engineering Practices: Centralized ESLint Configuration

Table of Contents

1. Introduction
2. Benefits
3. How to create a central ESLint configuration
4. Frequently asked questions
5. Conclusion

Introduction

As a Chapter Lead, I'm always seeking ways to optimize our processes, improve collaboration, and drive excellence within our teams. This means automating most of the tasks that can be automated. For instance, the linting, problem arises when we have multiple projects, and repositories each one using a different linting strategy. In this blog post, we'll explore the benefits of having a centralized ESLint configuration and how it contributes to improved engineering practices, ultimately leading to better quality software developed faster.

Benefits

1. Single Source of Truth: One of the key advantages of a centralized ESLint configuration is ensuring consistency across all projects within an organization. By defining a standard set of linting rules and configurations, every engineer can adhere to the same coding standards, regardless of the project they're working on.

2. Time Savings: Updates and modifications to the recommended configurations can be made in one central location. This simplifies the maintenance process as there's no need to update configurations across multiple repositories or projects individually. Also, setting up ESLint configurations for each project individually can be time-consuming, especially in larger organizations with multiple projects.

3. Versioning and History: A central repository allows for versioning and tracking changes to the recommended configurations over time. This provides visibility into the evolution of coding standards and allows teams to roll back changes if needed.

4. Collaboration and Communication: A central repository encourages collaboration and communication among team members. Engineers can contribute to the improvement of recommended configurations through discussions, feedback, and pull requests. Also, reduces the cognitive overhead of switching between projects.

5. Reduced Risk: Maintaining a consistent ESLint configuration helps reduce the risk of introducing bugs and inconsistencies into the codebase. By enforcing best practices and catching potential issues early during development, teams can prevent common pitfalls and ensure a higher level of code quality.

6. Faster Development: Centralized ESLint configurations enable engineers to focus more on writing code and less on manual linting and code review processes. By automating code quality checks and providing instant feedback during development, teams can iterate faster and deliver features more efficiently.

How to create a central ESLint configuration?

First, we need to create a new project, this would be the package.json

{
  "name": "@naveira/eslint-recommended",
  "version": "1.0.0",
  "description": "A centralized ESLint configuration package for @naveira/eslint-recommended",
  "scripts": {
  },
  "keywords": [
    "eslint",
    "typescript",
    "react",
    "linting",
    "coding standards"
  ],
  "author": "Gonzalo Naveira",
  "license": "MIT",
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^5.3.0",
    "@typescript-eslint/parser": "^5.3.0",
    "eslint": "^8.10.0",
    "eslint-plugin-react": "^7.29.2",
    "eslint-plugin-react-hooks": "^4.3.0"
  }
}

This is using some recommended linting rules for a project using Typescript and React. The name is going to be the name of our linting rule.

Create an .eslintrc.json file in the root directory of your package, this is an example file using the previous rules:

{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint", "react", "react-hooks"],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:react/recommended",
    "plugin:react-hooks/recommended"
  ],
  "settings": {
    "react": {
      "version": "detect"
    }
  },
  "rules": {
    "@typescript-eslint/explicit-function-return-type": "off",
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-explicit-any": "off",
    "react/prop-types": "off",
    "react/react-in-jsx-scope": "off"
  }
}

• Publish the package: Once you've created the package and configured the ESLint rules, you can publish it to npm by running:

npm publish --access public

• Other projects can now use your package by installing it in their projects and extending the configuration in their ESLint configuration file:

npm install --save-dev @naveira/eslint-recommended

• The updated .eslintrc.json would look like this:

{
  "extends": [ "@naveira/eslint-recommended" ]
}

Frequently asked questions

• What if I need to handle different rules for a specific project?

We need to understand how to serve the project's that for many reasons might not be 100% aligned. For these cases, we could overwrite the particular rules we need until we can remove the overwrites.

{
  "extends": ["@naveira/eslint-recommended"],
  "rules": {
    // Override specific rules here
    "no-unused-vars": "off",
    "indent": ["error", 4]
  }
}

• How can teams effectively manage updates to the centralized ESLint configuration without disrupting ongoing projects?

Another problem might be updating the rules, for this scenario, it's simply handled by the package.json version, we should aim to follow a sem ver strategy for versioning our centralised ESLint.

{
  "devDependencies": {
    "@naveira/eslint-recommended": "1.0.0"
  }
}

• Are there any potential drawbacks or challenges in adopting a centralized ESLint configuration across diverse projects?

Developers/teams may be resistant to adopting a centralized ESLint configuration, especially if they are accustomed to their linting setups or if the new configuration introduces significant changes to their workflow. Resistance to change can hinder adoption and implementation across diverse projects. We also need to consider that the process to update and maintain these rules now will impact all the projects that are using it.

• Can the centralized ESLint configuration be extended to include additional rules or plugins based on project-specific needs?

This approach can be extended to any other Javascript or Typescript framework without issues.

Conclusion

In conclusion, adopting a centralized ESLint configuration is a strategic decision that can significantly improve engineering practices and enhance the quality of software development. By promoting consistency, saving time, reducing risk, and enabling faster development cycles, centralized ESLint configurations empower teams to deliver better software in less time.