Concept 13: Code Quality & Validation

Introduction

Learn the automated tools and workflows that separate hobby projects from production-ready applications: linting, build pipelines, and professional version control practices.

Learning Objectives

By the end of this lesson, you will:

• Understand ESLint and automated code quality checking
• Run professional build pipelines (lint -> type-check -> build)
• Write professional commit messages using conventional commits format
• Apply comprehensive quality gates before submission

Duration: ~40 minutes

Part One: Linting & Code Quality (15 minutes)

What Is Linting?

Linting is automated code checking for errors, bugs, style issues, and best practice violations.

Why linting matters:

• Catches bugs early: Find errors before running code
• Maintains consistency: Everyone on the team writes similar code
• Improves readability: Standardized formatting makes code easier to understand
• Prevents common mistakes: Warns about problematic patterns

Example:

// Without linting - compiles but has issues
var user = "Alice"
const getData = function() { return data }
console.log("Debug info")

// With linting - clean and consistent
const user = 'Alice';
const getData = () => data;
// No console.log in production code

What Is ESLint?

ESLint is the industry-standard linting tool for JavaScript and TypeScript.

Key features:

• Detects syntax errors before runtime
• Enforces coding standards (quotes, semicolons, indentation)
• Identifies unused variables and imports
• Suggests best practices
• Auto-fixes many issues with --fix flag

Installation:

# Install ESLint
npm install --save-dev eslint

# Initialize configuration
npx eslint --init

For existing projects: Most React/Next.js templates include ESLint by default. Check your package.json for the eslint script.

Common ESLint Rules

One. no-unused-vars (Detect unused variables)

// ❌ ESLint error: 'score' is defined but never used
const score = 100;
const name = 'Alice';
console.log(name);

// ✅ Fix: Remove or use the variable
const name = 'Alice';
console.log(name);

Why this matters: Unused variables clutter code and may indicate bugs (you meant to use it but forgot).

2. no-console (Prevent console.log in production)

// ❌ ESLint warning: Unexpected console statement
function processData(data) {
  console.log('Processing:', data);
  return data.filter(x => x > 0);
}

// ✅ Fix: Use proper logging library or remove
function processData(data) {
  // Use logger.info() for production
  return data.filter(x => x > 0);
}

Why this matters: console.log is for debugging. Production apps should use proper logging systems.

3. prefer-const (Use const for variables that don't change)

// ❌ ESLint error: 'userName' is never reassigned. Use 'const' instead
let userName = 'Alice';
console.log(userName);

// ✅ Fix: Use const
const userName = 'Alice';
console.log(userName);

Why this matters: const signals intent - this value won't change. Prevents accidental reassignment.

4. eqeqeq (Require === instead of ==)

// ❌ ESLint error: Expected '===' and instead saw '=='
if (score == 100) {
  console.log('Perfect!');
}

// ✅ Fix: Use strict equality
if (score === 100) {
  console.log('Perfect!');
}

Why this matters: == performs type coercion ('5' == 5 is true), causing unexpected bugs. === is safer.

5. no-var (Disallow var, use let/const)

// ❌ ESLint error: Unexpected var, use let or const instead
var count = 0;

// ✅ Fix: Use let or const
let count = 0;

Why this matters: var has confusing scoping rules. let and const are block-scoped and clearer.

Running ESLint

Basic usage:

# Lint all JavaScript files
npx eslint .

# Lint specific file
npx eslint src/game.js

# Auto-fix issues
npx eslint --fix .

Reading ESLint Output

Example output:

$ npx eslint src/

/src/game.js
  12:7   error    'score' is assigned a value but never used    no-unused-vars
  23:3   warning  Unexpected console statement                  no-console
  45:9   error    Expected '===' and instead saw '=='           eqeqeq
  67:5   error    Unexpected var, use let or const instead      no-var

✖ 4 problems (3 errors, 1 warning)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

Interpretation:

• Line 12: Remove unused score variable
• Line 23: Remove console.log() or disable rule
• Line 45: Change == to ===
• Line 67: Change var to let or const
• 2 errors auto-fixable: Run eslint --fix to auto-correct

The Auto-Fix Workflow

Step One: Check for issues

npx eslint .

Step 2: Auto-fix what's possible

npx eslint --fix .

Step 3: Manually fix remaining issues ESLint will show errors it can't auto-fix. Address these one by one.

💡 Tip: Run eslint --fix multiple times. Some fixes enable other fixes!

ESLint Configuration

Modern ESLint 9+ (flat config) - eslint.config.js:

import js from '@eslint/js';

export default [
  js.configs.recommended,
  {
    languageOptions: {
      ecmaVersion: 'latest',
      sourceType: 'module',
      globals: {
        browser: true,
        node: true,
        es2021: true,
      },
    },
    rules: {
      'no-console': 'warn',      // Warn on console.log
      'no-unused-vars': 'error', // Error on unused vars
      'prefer-const': 'error',   // Error if let should be const
      'eqeqeq': 'error',         // Require ===
      'no-var': 'error',         // Ban var keyword
    },
  },
];

Legacy ESLint 8 (still supported) - .eslintrc.js:

module.exports = {
  env: { browser: true, es2021: true, node: true },
  extends: ['eslint:recommended'],
  parserOptions: { ecmaVersion: 'latest', sourceType: 'module' },
  rules: {
    'no-console': 'warn',
    'no-unused-vars': 'error',
    'prefer-const': 'error',
  },
};

💡 Tip: ESLint 9+ uses flat config format (export default array). For migration guide: npx @eslint/migrate-config .eslintrc.js

Rule levels:

• 'off' or 0: Rule disabled
• 'warn' or 1: Show warning (doesn't break build)
• 'error' or 2: Show error (breaks build)

Part 2: Production Build Pipeline (10 minutes)

The Professional Workflow

1. Lint       → Check code quality (ESLint)
2. Type-check → Verify TypeScript types (tsc)
3. Build      → Compile for production (Vite/Webpack)
4. Deploy     → Push to production

Before submitting your projects, run the full quality pipeline to ensure production readiness:

pnpm lint:fix && pnpm type-check && pnpm build

Step One: Linting

Command:

pnpm lint:fix

Expected output (success):

> eslint --fix .

✔ All files pass linting

If errors appear: Review and fix them manually. Common issues:

• Unused imports: Remove them
• Missing dependencies: Add to package.json
• Syntax errors: Fix typos or incorrect code

Step 2: Type Checking (TypeScript Projects)

Command:

pnpm type-check

Expected output (success):

> tsc --noEmit

✔ No type errors found

If errors appear: Add missing properties to match TypeScript interfaces.

💡 Tip: TypeScript errors indicate potential runtime bugs. Fix them now to avoid crashes later!

Step 3: Production Build

Command:

pnpm build

Expected output (success):

> vite build

✓ 156 modules transformed
✓ built in 2.3s
dist/index.html                   1.2 kB
dist/assets/index-a4b3c5d2.js    45.8 kB

If build fails:

Common errors:

• Module Not Found: Create missing file or fix import path
• Type Error: Add missing properties to match TypeScript interfaces

Setting Up Your Validation Script

Add to package.json:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "lint": "eslint .",
    "lint:fix": "eslint --fix .",
    "type-check": "tsc --noEmit",
    "validate": "pnpm lint:fix && pnpm type-check && pnpm build"
  }
}

Usage:

# Development mode (hot reload)
pnpm dev

# Full validation before commit
pnpm validate

What happens when you run pnpm validate:

1. Auto-fixes linting issues
2. Checks TypeScript types
3. Builds production version
4. Only succeeds if ALL steps pass

💡 Tip: Always run pnpm validate before pushing code to GitHub. This catches issues early and prevents breaking the build. Make it your pre-submission ritual!

Part 3: Professional Commit Messages (10 minutes)

Good vs. Bad Commit Messages

Conventional Commits Format

feat: Add new feature
fix: Fix bug or error
docs: Update documentation
style: Format code (whitespace, semicolons)
refactor: Restructure without changing functionality
test: Add or update tests
chore: Maintenance tasks (dependencies, config)

Examples for AI projects:

feat: Implement AI chat integration with OpenAI API
fix: Resolve crash when user submits empty input
refactor: Extract scoring logic into separate module
docs: Add API documentation and usage examples
test: Add unit tests for form validation
chore: Update dependencies to latest versions

When to Commit

Commit after:

• Completing a feature ("feat: Add user authentication")
• Fixing a bug ("fix: Resolve login redirect issue")
• Before experimenting ("Checkpoint before major refactoring")
• Significant refactoring ("refactor: Restructure component hierarchy")

How often? More is better! Aim for 5-10 commits per day of active development.

Writing Detailed Commits

git add src/knowledge-base.js
git commit -m "feat: Create Smart Farm knowledge base with 50+ Q&A pairs

- Organized by categories: crops, weather, pests, soil
- Added difficulty ratings for beginner/advanced responses
- Implemented JSON structure for easy extension"

Why this works:

• Clear title line (feature type + what was added)
• Detailed body explaining the implementation
• Shows intentional design decisions

💡 Tip: If you can't write a clear commit message, your commit might be doing too much. Break it into smaller, focused commits!

Git Best Practices

Before committing:

# Review what changed
git status
git diff

# Stage specific files
git add src/components/Game.jsx
git add src/styles/game.css

# Commit with descriptive message
git commit -m "feat: Add game timer with pause functionality"

Amend last commit (if needed):

# Add forgotten file to last commit
git add forgotten-file.js
git commit --amend --no-edit

View commit history:

# See commit log
git log --oneline

# See last 5 commits
git log --oneline -5

# See commits with file changes
git log --stat

Part 4: Pre-Submission Quality Gates (5 minutes)

Comprehensive Quality Checklist

Code Quality

• Run pnpm validate - all checks pass
• Remove all console.log() debug statements
• No unused variables or imports
• Code follows consistent style (ESLint enforced)

Functionality

• All core features work as specified
• Tested on clean install (npm install in new folder)
• No runtime errors in browser console
• Edge cases handled (empty inputs, API failures)

Documentation

• README.md includes setup instructions
• Code comments explain complex logic
• API keys documented (but not committed!)
• Usage examples provided

Version Control

• All changes committed with descriptive messages
• Final commit message: "chore: Final submission for [Project Name]"
• Pushed to GitHub (or submitted via required method)
• .gitignore excludes node_modules/, .env

Submission Requirements

• Follows project rubric specifications
• Includes required files (as specified in project brief)
• Submission form completed
• Deadline met

The Final Validation Command

Run this before submission:

# Full pipeline
pnpm validate

# If successful, commit
git add .
git commit -m "chore: Final submission - passed all quality checks"
git push origin main

What this proves:

• Your code lints successfully
• TypeScript types are correct (if applicable)
• Production build completes without errors
• Project is ready for evaluation

Testing Clean Install

# Clone to new directory
cd /tmp
git clone https://github.com/yourusername/your-project.git
cd your-project

# Install dependencies
npm install

# Run build pipeline
npm run validate

# Test application
npm run dev

If any step fails: Fix it before submission!

Summary

Linting & Code Quality:

• ESLint catches errors and enforces standards
• Common rules: no-unused-vars, no-console, prefer-const, eqeqeq, no-var
• Use eslint --fix to auto-correct issues
• Configuration through .eslintrc.js

Build Pipeline:

• Professional workflow: Lint -> Type-check -> Build -> Deploy
• Command: pnpm lint:fix && pnpm type-check && pnpm build
• Interpreting build errors (type errors, missing modules)
• Use pnpm validate for one-command quality checks

Professional Commit Messages:

• Conventional commits format (feat:, fix:, docs:, refactor:, etc.)
• Descriptive, concise, action-oriented
• Document project evolution for yourself and evaluators
• Commit frequently (5-10 times per active development day)

Pre-Submission Quality Gates:

• Code quality verification (linting, no debug statements)
• Functionality testing (works on clean install)
• Documentation completeness (README, comments)
• Version control best practices (descriptive commits, proper .gitignore)

Next Steps

Daily workflow:

1. Work on features
2. Commit with descriptive messages
3. Run pnpm validate periodically
4. Fix any issues immediately

Before submission:

1. Complete pre-submission checklist
2. Run final pnpm validate
3. Test clean install
4. Review commit history
5. Submit with confidence!

In upcoming activities, you'll practice these quality assurance workflows on real projects!

Key Takeaways

💡 Remember: Professional development isn't just about working code-it's about maintainable, efficient, and scalable systems that stand the test of time.

The Professional Development Mindset:

• "Is my code clean and readable?"
• "Can I automate quality checks?"
• "Does my commit history show intentional development?"
• "Will my project work on someone else's machine?"
• "Have I documented complex decisions?"

Before pushing code:

pnpm lint:fix      # Clean code ✓
pnpm type-check    # Type-safe ✓
pnpm build         # Builds successfully ✓
git log --oneline  # Professional history ✓

Your submission represents not just what you built, but HOW you built it. Make it count!