Master Table of Contents

• See full index in [01. Introduction]

Who this chapter is for

• Learners who want cleaner code with less manual policing
• Solo developers and teams building production-ready habits
• Anyone who is tired of “works on my machine” surprises

What you’ll learn

• Practical ESLint and Prettier setup that teams can actually maintain
• Why TypeScript strict mode prevents expensive bugs early
• How to automate quality checks with scripts and pre-commit hooks

Why this topic matters

Good tooling turns code quality from “reminder culture” into a system.

Instead of depending on memory, you let automation catch issues early. That means smoother code reviews, safer merges, and fewer avoidable production problems.

Core concepts

Linting

• Catch suspicious patterns and bad practices

Linting protects code quality rules consistently across contributors.

Formatting

• Keep style consistent across contributors

Formatting removes style debates so reviews can focus on logic.

Type strictness

• Detect null/undefined and mismatch risks earlier

Strict typing catches a lot of “silent bug” scenarios before runtime.

Step-by-step walkthrough

Step 1 — Configure lint and format

Set up ESLint + Prettier baseline and make sure they do not conflict.

Step 2 — Enable strict TypeScript options

Enable strict options gradually if needed, but keep a clear target to reach full strictness.

Step 3 — Automate checks

Create one command to run all quality checks before merge.

Goal: quality gates are automatic, not optional.

Practical examples

Example 1 — Quality scripts

{
	"scripts": {
		"lint": "eslint .",
		"format": "prettier --write .",
		"typecheck": "tsc --noEmit",
		"check": "npm run lint && npm run typecheck"
	}
}

Tip:

• Keep check fast enough to run regularly in daily development.

Example 2 — Pre-commit concept

• Run lint and typecheck before allowing commit

This blocks low-quality commits before they hit shared branches.

Common mistakes and how to avoid them

• Treating lint errors as optional -> fix or explicitly document exceptions
• Auto-formatting without checking diffs -> still review meaningful changes
• Delaying strict mode too long -> introduce strictness early while codebase is smaller
• Too many tools with unclear purpose -> keep a minimal, useful tooling stack

Mini Project

• Add a complete quality pipeline to one project with:
• ESLint,
• Prettier,
• TypeScript typecheck,
• pre-commit check.

Bonus:

• Add CI check so pull requests fail automatically when quality checks fail.

Quick practice

• Fix one lint issue and one type issue
• Add one check script
• Run checks before each commit
• Write one short team rule: “When can lint rules be disabled?”

Key takeaways

• Tooling makes quality repeatable and less dependent on memory
• Strict typing catches high-impact bugs earlier
• Automated quality gates speed up collaboration and reduce review friction

Next step

Continue to [17. Backend Basics with Node.js]