Linting & Formatting (ESLint/Prettier strategy)

Learn how to use ESLint and Prettier in Node.js projects to enforce code quality, prevent common mistakes, and maintain consistency across teams.

On this page

Why Linting Is Not Optional

Linting is automated code review. It catches bugs, enforces standards, and prevents small mistakes from becoming production incidents.

ESLint Installation

npm install -D eslint
npx eslint --init

TypeScript Support

npm install -D @typescript-eslint/parser @typescript-eslint/eslint-plugin

Example ESLint Config

{
  "parser": "@typescript-eslint/parser",
  "plugins": ["@typescript-eslint"],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ]
}

Common Rules That Matter in Backends

No unused variables
No floating promises
Consistent return types
No implicit any

Formatting with Prettier

npm install -D prettier

Example Prettier Config

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all"
}

Script Integration

{
  "scripts": {
    "lint": "eslint .",
    "format": "prettier --write ."
  }
}

CI Integration

In CI pipelines, run linting before tests:

npm ci
npm run lint
npm test

Production Insight

Linting reduces bug density.
Formatting reduces diff noise in pull requests.
Automated checks improve team velocity long-term.

Pre-Commit Hooks

Advanced teams integrate linting into pre-commit hooks to prevent bad code from entering the repository.

JS Note

Linting is even more important in JavaScript-only projects because there is no compile-time type checking.

Final Insight

Tooling discipline early prevents architecture decay later. Clean codebases scale better than clever ones.

← Project Structure: Feature vs Layer Folders