ESLint checks JavaScript source code against enforceable rules. It can flag potential errors, inconsistent practices, and style violations before they reach teammates. For a React team, that makes an agreed coding standard something the project can check rather than something every reviewer must remember. section 4.1 section 4.1.1
Rules are configurable: a violation can be an error or a warning, and many violations can be fixed automatically. You can choose rules individually or extend a predefined set such as `eslint:recommended`. A shared configuration is useful when the team wants consistent checks without depending on each developer’s editor setup. section 4.1.1 section 4.1.2
Choose and override rules
In the configuration format shown here, `"extends": "eslint:recommended"` starts with a predefined ruleset. A `rules` entry such as `"semi": ["error", "always"]` then makes missing semicolons errors; `"semi": ["error", "never"]` expresses the opposite team preference. The choice is a policy decision, not a universal requirement. section 4.1.2 section 4.1.3
A practical setup has three steps:
- Run `npm init @eslint/config` to initialize ESLint. section 4.1.3
- Review the generated project-root `.eslintrc.{js,yml,json}` file; extend a ruleset and add overrides if needed. section 4.1.3
- Enable checks in the editor and build so violations appear while writing code and in the project workflow. section 4.1.3
Keep ESLint’s role distinct from adjacent tools. A formatter such as Prettier automates formatting, while linting also checks coding mistakes and practices. Their responsibilities overlap, so select rules with the rest of the project’s tooling in mind. section 4.0 section 4.5
