Chapter 42: Node.js Linting & Formatting

1. Why linting & formatting matters so much in Node.js projects

  • Node.js projects tend to grow quickly and involve many developers → style chaos happens fast
  • JavaScript is extremely flexible → many ways to write the same thing → teams waste time debating style
  • TypeScript makes structural errors obvious, but style, readability, consistency and potential bugs are still invisible without linting
  • Good linting catches subtle bugs that TypeScript misses (no-unused-vars with conditions, no-console in production, etc.)
  • Automatic formatting removes 95% of style discussions → people focus on logic instead of tabs vs spaces

Two separate responsibilities (very important distinction):

Responsibility Tool family today (2025–2026) Goal Runs on save? Blocks commit?
Formatting Prettier Consistent visual style (spaces, quotes, semicolons, line length…) Yes No (usually)
Linting ESLint + typescript-eslint Code quality, potential bugs, best practices, style rules that Prettier doesn’t handle Yes Yes (usually)

Golden rule used by almost all good teams today:

Prettier handles how the code looks ESLint handles whether the code is correct / safe / maintainable

2. Modern recommended stack (2025–2026)

Tool Purpose Current best version (early 2026) Why it wins right now
Prettier Code formatting 3.3.x De-facto standard, huge ecosystem
ESLint Linting & quality rules 9.x (flat config) ESLint 9 flat config is finally good
typescript-eslint TypeScript-specific rules 8.x Excellent integration with ESLint 9
eslint-config-standard-with-typescript Popular sane defaults (optional) 43.x Good starting point if you like StandardJS style
prettier-plugin-tailwindcss Sort Tailwind classes (if using Tailwind) latest Essential if you use Tailwind
lint-staged Run lint/format only on git staged files 15.x Makes pre-commit fast
husky Git hooks (pre-commit, pre-push) 9.x Simple & reliable

3. Step-by-step: Setting up a modern Node.js + TypeScript linting & formatting environment

Create a new project (or use existing one)

Bash

Install everything

Bash

Initialize TypeScript

Bash

Create .prettierrc (JSON or .prettierrc.cjs)

JSON

Create .prettierignore

text

Create eslint.config.mjs (ESLint 9+ flat config – the modern way)

JavaScript

Create .eslintrc.ignore (optional)

text

Add lint-staged + husky (run on git commit)

JSON
Bash

Now every commit will:

  • Run ESLint + auto-fix on staged .ts / .js files
  • Run Prettier on staged files

4. Realistic example files – what good code looks like

src/index.ts

TypeScript

src/utils/logger.ts

TypeScript

Run linters manually:

Bash

5. Summary – Modern linting & formatting checklist (2025–2026)

Task / Goal Tool / Setting Typical command / config
Format on save Prettier + VS Code extension Editor: “editor.formatOnSave”: true
Lint on save ESLint + VS Code extension Editor: “eslint.format.enable”: true
Auto-fix on commit lint-staged + husky pre-commit hook: npx lint-staged
Use flat config (ESLint 9+) eslint.config.mjs / .js Recommended for new projects
Strict TypeScript rules @typescript-eslint/recommended + stylistic Catches many subtle bugs
No unused variables ‘@typescript-eslint/no-unused-vars’ Must be ‘error’ in serious projects
Prefer const over let when possible ‘prefer-const’ Enabled by default in most configs
No console.log in production code ‘no-console’ with allow: [‘warn’, ‘error’] Very common rule

Which topic would you like to go much deeper into next?

  • Full ESLint flat config with 30–40 real rules (strict mode)
  • Prettier vs ESLint style rules conflict resolution
  • lint-staged + husky setup with pre-push checks
  • Tailwind + prettier-plugin-tailwindcss perfect setup
  • TypeScript + ESLint best rules for large Node.js backends

Just tell me what you want to focus on — I’ll go as deep as you like with complete files and explanations. 😊

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *