ESLint, TypeScript, and Why CI Should Break Your Builds

Most developers treat errors differently depending on where they see them.

• In editor → "I'll fix it later"
• In terminal → "Not now"
• In production → "Oh shit"

That's the problem.

---

The Goal

If the code is broken, it should never reach production.

Not "we'll fix it later." Not "it's just a warning."

Never.

---

ESLint + TypeScript Are Not Suggestions

• ESLint → code quality + consistency
• TypeScript → type safety + correctness

Together, they're your first line of defense.

But only if you take them seriously.

---

The Problem Without CI

Even if you:

• Run lint locally
• Use TypeScript

Things still slip through.

Why?

• Someone skips checks
• Someone pushes quickly
• Someone ignores warnings

Local discipline doesn't scale.

---

Enter CI (Continuous Integration)

CI enforces rules automatically.

No opinions. No exceptions.

If it fails, it doesn't ship.

---

What I Enforce in CI

At minimum:

npm run lint
npm run type-check
npm run build

If any of these fail → the PR is blocked.

---

Example: GitHub Actions Setup

Create .github/workflows/ci.yml:

name: CI

on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Node
        uses: actions/setup-node@v3
        with:
          node-version: 18

      - name: Install dependencies
        run: npm install

      - name: Run ESLint
        run: npm run lint

      - name: Type Check
        run: npm run type-check

      - name: Build
        run: npm run build

---

Make Errors Fail the Build

In your package.json:

{
  "scripts": {
    "lint": "eslint . --max-warnings=0",
    "type-check": "tsc --noEmit",
    "build": "next build"
  }
}

Why this matters:

• --max-warnings=0 → warnings = failure
• tsc --noEmit → pure type validation
• Build step → catches runtime/config issues

---

Why CI Is Better

1. It Removes Human Error

You don't rely on:

• Memory
• Discipline
• Good intentions

It just runs.

2. It Standardizes Quality

Everyone follows the same rules.

No "works on my machine."

3. It Protects Production

Bad code never reaches main.

4. It Scales With Teams

The bigger the team → the more important CI becomes.

---

My Rule

If CI fails, the code doesn't exist.

Simple.

---

Final Thought

Speed matters. But speed without guardrails slows you down later. CI is those guardrails.

Your future self (and your team) will thank you.