Code Linting

Code linting automatically checks your code for style issues, bugs, and formatting problems before it’s merged.
In our practicum repos, linting is handled by ESLint and Prettier, both locally (in your editor) and in CI (GitHub Actions).

Linting exists to catch mistakes early and keep the codebase consistent, no matter who is writing the code.

---

How Linting Works in Our Repos

View Repo Linting Overview

Most practicum JavaScript/TypeScript projects share the same basic setup:

1. ESLint + Prettier Installed as Dev Dependencies

In package.json you’ll usually see:

{
  "devDependencies": {
    "eslint": "...",
    "@typescript-eslint/eslint-plugin": "...",
    "@typescript-eslint/parser": "...",
    "eslint-config-prettier": "...",
    "eslint-plugin-react": "...",
    "prettier": "..."
  }
}

These packages provide:

• ESLint → finds code issues & style violations
• Prettier → formats code (spacing, quotes, semicolons, etc.)
• eslint-config-prettier → prevents conflicts between ESLint & Prettier

2. Shared Configuration Files

In the root of the repo you’ll typically find:

• .eslintrc.* → ESLint rules & environment
• .prettierrc or prettier.config.* → Prettier rules

Example ESLint config (simplified):

{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier"
  ],
  "parser": "@typescript-eslint/parser",
  "rules": {
    "no-unused-vars": "warn",
    "no-console": "off",
    "@typescript-eslint/no-explicit-any": "warn"
  }
}

3. NPM Scripts for Linting

{
  "scripts": {
    "lint": "eslint \"src/**/*.{js,jsx,ts,tsx}\"",
    "lint:fix": "eslint \"src/**/*.{js,jsx,ts,tsx}\" --fix"
  }
}

You’ll run these locally with:

npm run lint
npm run lint:fix

---

What Happens Locally (In Your Editor)

View Local Linting Behavior

ESLint + Prettier in VS Code / WebStorm

Once ESLint and Prettier are configured:

• Your editor shows red/yellow squiggles under problematic code
• The Problems panel lists errors and warnings
• Quick-fix actions can often auto-correct issues
• With “format on save,” Prettier cleans up formatting every time you save

In VS Code this is powered by the ESLint extension, which integrates ESLint results directly into the editor.

Typical Local Flow

1. You write or edit code
2. ESLint analyzes the file and flags issues in real time
3. Prettier formats your code on save
4. You fix any remaining ESLint warnings/errors
5. You commit only after the file is clean

This local feedback loop prevents a lot of noisy CI failures later.

---

What Happens in CI (GitHub Actions)

View CI Linting Workflow

When you open a Pull Request:

1. GitHub Actions runs a lint workflow (usually npm run lint)
2. If ESLint finds errors, the workflow fails
3. GitHub marks the PR with a ❌ check and may block merging until fixed
4. Once you push a fix and the workflow passes, checks turn ✅

A typical CI job might look like this:

name: Lint

on:
  pull_request:
    branches: [ main, develop ]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint

In the PR view, you’ll see these checks listed under “Checks” or near the merge button — similar to other GitHub workflow status checks.

Lint failures are fast feedback: they tell you something is off before a reviewer even starts reading your code.

---