Go from building components to shipping production front-ends: architecture, TypeScript, state, performance, testing, CI and code review.

Front-End Engineering

Pick a project of your own (for example the Vite app from the code-splitting lesson) and push it to a GitHub repository if it is not there already.

Make sure `package.json` has `lint`, `test` (run once, for example `vitest run`) and `build` scripts, plus `typecheck` (`tsc --noEmit`) if the project uses TypeScript. Run each one locally and fix any failures first.

Add a `.nvmrc` file containing your Node major version (for example `22`) and commit `package-lock.json`.

Create `.github/workflows/ci.yml` with the workflow from the reading (triggers on pull_request and push to main, `permissions: contents: read`, checkout, setup-node with npm cache, then npm ci, lint, typecheck, test, build). Remove the typecheck step if you have no TypeScript.

Commit on a new branch, push, and open a pull request. Watch the run in the PR's Checks tab until it is green.

Break it on purpose: add an unused variable or a failing test, push, and confirm the PR shows a red cross. Open the failed step and find the first error line.

Fix the problem, push again, and confirm the older run was cancelled (concurrency) and the new one is green.

In the repository's Settings, add a branch protection rule or ruleset for main that requires the CI check to pass before merging. Then merge your PR.

## Why it matters

"It works on my machine" is not a release process. **Continuous integration (CI)** runs the same checks on a clean machine for every push and pull request, so broken code is caught before it is merged, not after it reaches users. On most front-end teams a pull request cannot be merged until CI is green, and setting up or fixing a pipeline is a normal mid-level task.

## What a front-end pipeline checks

A typical pipeline runs these steps, cheapest first, so failures show up quickly:

1. **Install** dependencies exactly as locked: `npm ci` (uses `package-lock.json`, fails if it is out of date).
2. **Lint**: `npm run lint` (ESLint, including accessibility and React hooks rules).
3. **Type check**: `npm run typecheck`, usually `tsc --noEmit`.
4. **Unit and integration tests**: `npm test` (Vitest or Jest) in run-once mode, not watch mode.
5. **Build**: `npm run build`, which catches import errors and framework build errors.
6. Optional, often in separate jobs: end-to-end tests (Playwright), a Lighthouse budget check, bundle size limits, and a preview deploy.

Make sure each of these is a script in `package.json`, so the commands are the same locally and in CI:

```json
{
  "scripts": {
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "build": "vite build"
  }
}
```

## GitHub Actions basics

GitHub Actions reads YAML **workflow** files from `.github/workflows/`. A workflow has **triggers** (`on`), one or more **jobs**, and each job has **steps** that run on a fresh virtual machine called a **runner**. Actions is free for public repositories, and private repositories get a monthly allowance of free minutes on GitHub's hosted runners (see [GitHub's billing docs](https://docs.github.com/en/billing/managing-billing-for-your-products/managing-billing-for-github-actions/about-billing-for-github-actions), checked on 2026-10-23).

```yaml
# .github/workflows/ci.yml
name: CI

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  check:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version-file: .nvmrc
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test
      - run: npm run build
```

What each part does:

- `on`: run on every pull request and on pushes to `main`.
- `permissions: contents: read`: give the job's token the least access it needs.
- `concurrency`: cancel an older run on the same branch when you push again, saving minutes.
- `actions/checkout`: clone the repository onto the runner.
- `actions/setup-node`: install the Node version from `.nvmrc` and cache npm's download cache between runs.
- Each `run` step is a shell command. If any exits with a non-zero code, the job fails and the PR shows a red cross.

## Making CI useful

- **Required checks.** In the repository settings, add a branch protection rule (or ruleset) for `main` that requires the CI job to pass before merging.
- **Fast feedback.** Cache dependencies, cancel superseded runs, and split slow work (e2e) into a separate job that runs in parallel.
- **Same as local.** Pin the Node version (`.nvmrc` or `engines`) and use `npm ci`, so CI and laptops agree.
- **Readable failures.** One step per check, so the failing step's name tells you what broke.
- **Secrets.** Never put tokens in the YAML. Store them as repository secrets and reference `${{ secrets.NAME }}`. Pull requests from forks do not receive secrets, which protects you from malicious PRs.
- **Coverage gates** (optional): fail the build when test coverage drops below an agreed threshold. Set the bar where it is today and only raise it.

## Reading a failed run

Open the PR's **Checks** tab, select the failed job and expand the red step. Read from the first error, not the last line. Common causes:

- `npm ci` fails: `package-lock.json` is out of sync. Run `npm install` locally and commit the lock file.
- Tests pass locally but fail in CI: they depend on your time zone, locale, an environment variable or test order.
- Build fails on case: macOS file systems are usually case-insensitive and Linux runners are not, so `import Button from './button'` breaks if the file is `Button.tsx`.

## Common mistakes

- Running `npm install` instead of `npm ci`, so CI quietly uses different versions.
- Running tests in watch mode, so the job hangs until it times out.
- Only running CI on `main`, after the bad code is merged.
- Letting a flaky test stay red, so people learn to ignore CI.
- Giving workflows broad token permissions or printing secrets in logs.

## Quick recap

- CI runs install, lint, type check, tests and build on a clean machine for every PR.
- GitHub Actions workflows live in `.github/workflows/` and are made of triggers, jobs and steps.
- Use `npm ci`, a pinned Node version, caching, least-privilege permissions and cancelled duplicate runs.
- Make the check required on `main`, and keep it fast and trustworthy.

## Try it

In the Do tab you add this pipeline to a repository of your own, break it on purpose, and fix it.


Set up a GitHub Actions workflow that runs lint, typecheck, tests and a build on every pull request.

CI for front-end

How to use GitHub Actions | GitHub for Beginners

What is GitHub Actions?

Choose a front-end PR with a visible UI change and read its description and any linked issue. Write one sentence describing what it should do.

Check the PR's CI status. Note whether lint, types, tests and build pass.

Run the change: check out the branch locally (`gh pr checkout <number>` or `git fetch origin pull/<number>/head:review && git switch review`) and start it, or open the preview deploy if there is one.

Test correctness in the browser: the main path, then loading, empty and error states (use DevTools Network throttling or offline mode to force slow and failed requests).

Test accessibility: use only the keyboard (Tab, Shift+Tab, Enter, Space, Esc), check that focus is visible, and run Lighthouse's Accessibility category or the axe DevTools extension on the changed screen.

Read the diff for security, performance and tests: user content in innerHTML, secrets, new heavy imports, images without dimensions, and whether the tests would fail if the feature broke.

Write at least four comments with severity labels (blocking, suggestion, question or nit), each with a reason, and at least one piece of specific praise.

Write a summary with a decision (approve, comment or request changes). If you reviewed your own old PR, list what you would do differently today.

## Why it matters

At junior level, code review is mostly something that happens to you. At mid level you are expected to review other people's pull requests (PRs) well: catch real bugs, spot accessibility and performance problems before users do, and do it in a way that helps the author instead of blocking them. Good reviewers make the whole team faster, and reviewing is one of the quickest ways to learn a codebase.

## Before you read the diff

1. **Read the description and linked issue.** What problem is this solving? What is out of scope? A good PR says how to test it and includes screenshots for UI changes.
2. **Check CI.** If lint, types or tests are red, ask for them to be fixed first; do not spend time reviewing code that will change.
3. **Check the size.** A 2,000-line PR cannot be reviewed well. It is fair to ask for it to be split.
4. **Run it if it is UI.** Pull the branch or open the preview deploy. Many front-end bugs are only visible in a browser.

## What to look for, in priority order

**1. Correctness.** Does it do what the issue asks, in every state?

- Loading, empty, error and success states all handled.
- Edge cases: zero items, very long text, a slow or failed request, a double click on submit.
- Race conditions: an older request finishing after a newer one and overwriting it.
- Data from the network validated; no assumptions that a field always exists.

**2. Accessibility.** Check it with the keyboard and the browser's accessibility tools, not by reading the code alone.

- Every interactive element is a real `button`, `a`, or form control, reachable with Tab and operable with Enter and Space.
- Visible focus is not removed; focus moves sensibly when a modal opens and returns when it closes.
- Inputs have labels; icon-only buttons have accessible names; images have meaningful (or empty) `alt`.
- Errors are announced (for example `role="alert"`) and not shown by colour alone.
- Headings stay in order; motion respects `prefers-reduced-motion`.

**3. Security and privacy.** No secrets in front-end code (anything in the bundle is public), no `dangerouslySetInnerHTML` or `innerHTML` with user content, no tokens in `localStorage` if the app uses httpOnly cookies, no personal data in logs.

**4. Performance.** A new heavy dependency on every page, an image without dimensions (layout shift), an effect that refetches on every render, or a list of thousands of items rendered at once.

**5. Tests.** Are the new behaviours tested at a sensible level? Would the tests fail if the feature broke?

**6. Maintainability.** Naming, structure, duplication, and fit with the existing patterns of the codebase. This matters, but it comes after the user-facing issues.

**Style** (quotes, spacing, import order) should be the formatter's and linter's job. If you keep commenting on it, propose a lint rule instead.

## Writing comments people can act on

- **Be specific and explain why.** "This button has no accessible name, so screen readers announce only 'button'. Could we add `aria-label=\"Close dialog\"`?" beats "a11y?".
- **Label severity.** Many teams use prefixes: **blocking** (must fix before merge), **suggestion**, **question**, **nit** (minor, optional). Authors then know what actually stops the merge.
- **Ask, do not command,** when you are not sure: "What happens if the request fails here?"
- **Offer code** with GitHub's suggestion feature for small fixes, so the author can apply it in one click.
- **Comment on the code, not the person.** "This function" not "you".
- **Praise what is good.** A clear test or a nice simplification is worth saying out loud.

Finish with a clear decision: **approve**, **comment**, or **request changes**, and a one-line summary such as "Looks good once the error state is handled; two nits are optional."

## Worked example

A PR adds a "Delete comment" button. Reading the diff and running the preview, you find:

- **blocking**: the button is `<span onClick>`; it is not keyboard reachable. Use `<button type="button">`.
- **blocking**: deletion happens immediately with no confirmation and no undo. The design spec asks for a confirm dialog.
- **question**: if the DELETE request fails, the comment disappears anyway because the list is updated optimistically without rollback. Is that intended?
- **suggestion**: the new `useDeleteComment` hook has no test; a component test for the success and failure paths would cover it.
- **nit**: `handleClick2` could be `handleDelete`.
- Praise: nice reuse of the existing ConfirmDialog in the other screen.

Decision: request changes, with the two blocking items called out at the top.

## Being reviewed well

The same skills apply in reverse: keep PRs small and focused, write a description with testing steps and screenshots, review your own diff first, respond to every comment (fix it, or explain why not), and do not take feedback personally.

## Common mistakes

- Approving without running UI changes.
- Fifty nit comments and no mention of the missing error state.
- Vague comments ("this is confusing") with no reason or suggestion.
- Blocking on personal preference that the codebase does not follow.
- Letting reviews sit for days; aim to respond within a working day.

## Quick recap

- Read the context, check CI and run the change before reading the diff in detail.
- Review in priority order: correctness, accessibility, security, performance, tests, then maintainability. Leave style to tools.
- Write specific, kind, labelled comments and end with a clear decision.

## Try it

In the Do tab you do a full review of a real pull request using this checklist.


Review a pull request for correctness, accessibility and maintainability, and give feedback people can act on.

Code review as a mid-level dev

Code Review Best Practices

How to Review a Pull Request Like a Senior Developer

Write a README with the problem, users, three user stories and an out-of-scope list, and sketch the main screens.

Scaffold with `npm create vite@latest <name> -- --template react-ts`, add ESLint, Vitest and React Testing Library, set up feature folders, and push to a new GitHub repository.

Add the GitHub Actions CI workflow (npm ci, lint, typecheck, test, build) and make it a required check on main.

Deploy the skeleton to a free static host (build `npm run build`, publish `dist`, SPA fallback configured) and confirm the live URL works, including a deep link reload.

Build each core feature in its own pull request with component tests for loading, empty, error and success states; self-review each PR with the code review checklist before merging.

Add at least one Playwright end-to-end test for the core journey (`npm init playwright@latest`) and run it locally.

Run Lighthouse (Mobile) and axe on every screen. Fix issues until Accessibility is 100, there are no serious axe violations, and lab LCP is under 2.5 s and CLS under 0.1 on the main page.

Do a keyboard-only run-through, a screen reader run-through (NVDA, VoiceOver or TalkBack) and a check with reduced motion turned on; fix what you find.

Finish the README: live link, screenshots, how to run, decisions and trade-offs, Lighthouse scores and test counts, and an accessibility statement.

Share the repo and live link with a peer or mentor and ask for a review of one pull request and of the app itself.

## Why it matters

Hiring managers for front-end roles look for evidence that you can ship, not just follow tutorials. A single small app that is **accessible, tested, fast, deployed and maintained through pull requests and CI** says more than ten unfinished clones. This capstone pulls together everything in the course: structure, TypeScript, state, performance, component design, testing, motion, CI and review.

## The brief

Build a small but real application with React (Vite, or a framework such as Next.js) and TypeScript. Pick something you would actually use. Good shapes:

- **A course or reading tracker**: list, filter and search items; add and edit; mark complete; a progress summary.
- **A public data browser**: search a free, keyless public API (for example Open Library or a government open-data API), with filters in the URL and a detail page.
- **A habit or study planner**: create habits, check them off, see streaks, export the data.

Keep the scope small enough to finish in two or three weekends. Depth beats features.

## The definition of done

Treat this as a checklist; each item maps to a lesson.

**Structure and types**
- Feature folders, a small shared `components/ui` layer and a framework-free `lib/`.
- TypeScript in strict mode; API responses validated at the boundary.

**State**
- URL state for search, filters and the current tab; server state through a data library or framework loaders (if you call an API); local state everywhere else; no derived state stored.

**Accessibility**
- Semantic HTML, one `h1` per page, labelled inputs, visible focus, keyboard-operable everything, a skip link.
- Lighthouse Accessibility 100 and no serious axe violations on the main screens; tested once with a screen reader.

**Performance**
- Lighthouse Performance in the green on the Mobile preset for the main page; LCP under 2.5 s and CLS under 0.1 in the lab.
- Route-level code splitting; images sized, in a modern format, with `srcset` and lazy loading below the fold.

**Components and motion**
- At least Button, Input and one dialog or disclosure built as reusable, accessible primitives.
- Transitions use transform and opacity only and honour `prefers-reduced-motion`.

**Testing**
- Unit tests for pure logic, component tests for each feature's main states (loading, empty, error, success), and one Playwright e2e test for the core journey.

**Delivery**
- GitHub Actions CI running lint, typecheck, tests and build on every PR; required on `main`.
- Work done in small PRs, each with a description; review your own PRs with the checklist from the previous lesson.
- Deployed to a free static host (Netlify, Vercel, Cloudflare Pages or GitHub Pages). No paid plan is needed for a portfolio app.

## A suggested plan

1. **Day 1: plan.** Write a one-page README: problem, users, three core user stories, and what is out of scope. Sketch the main screens.
2. **Day 2: skeleton.** `npm create vite@latest` with the `react-ts` template, ESLint, Vitest, folder structure, CI workflow, first deploy of a "hello" page. Deploying on day one removes the scariest step from the end.
3. **Days 3–5: features.** One feature per PR, with tests in the same PR.
4. **Day 6: quality pass.** Lighthouse and axe on every screen, keyboard and screen reader run-through, reduced-motion check, fix what you find.
5. **Day 7: polish and present.** Empty and error states, a 404 page, README with screenshots and decisions.

## Deploying a Vite app

Static hosts build from your repository:

- **Build command:** `npm run build`
- **Publish directory:** `dist`
- **Single-page app routing:** if you use client-side routes, configure a fallback so `/courses/42` serves `index.html` (a `_redirects` rule `/* /index.html 200` on Netlify, a rewrite on Vercel, or a `404.html` copy on GitHub Pages).
- **Environment variables:** anything read on the client (for example Vite's `VITE_` variables) ends up in the public bundle. Never put secrets there.

## Presenting it

Your README is the first thing a reviewer reads. Include:

- What it does and a link to the live site, with two or three screenshots.
- How to run it locally (`npm ci`, `npm run dev`, `npm test`).
- **Decisions**: why you chose this rendering strategy, state approach and folder structure, and what you would do next.
- **Quality evidence**: Lighthouse scores, test counts, a short accessibility statement listing what you tested and any known gaps.

Be ready to talk through one hard bug you fixed and one trade-off you made. That conversation is often the most valuable part of an interview.

## Common mistakes

- Scope creep: a half-finished app with twelve features impresses less than a finished one with three.
- Deploying only at the end and discovering routing or environment problems on the last day.
- One giant commit at the end instead of PRs that show how you work.
- Copying a tutorial project without changes; reviewers recognise them.
- Leaving accessibility and tests "for later".

## Quick recap

- Build one small, real app and finish it to a professional standard.
- Use the definition of done: structure, types, state, accessibility, performance, components, motion, tests and CI.
- Deploy early to a free host, work in small PRs, and document decisions and quality evidence in the README.

## Try it

The Do tab breaks the capstone into concrete steps you can tick off as you go.


Plan, build, test and deploy an accessible, fast React app with CI, then present it as portfolio work.

Capstone: production-ready app

Deploy Vite app to GitHub Pages using GitHub Actions

Run lint, typecheck, tests and build in CI, review pull requests like a mid-level developer, and ship a production-ready capstone.