My progress
Menu

Frontend Developer · Focus area 3: Build tools and testing

FE7: The modern frontend toolkit

Goal: set up and use the tools around frontend code: what build tools such as Vite and Webpack do, TypeScript for safer components and data, Tailwind CSS and design tokens, linting and formatting, and handling environments, configuration and error monitoring.

You'll need: Node.js, your Kirana Express project, a code editor with TypeScript support (such as VS Code), and Git.

Where this is used: almost every professional frontend team works with a build tool, TypeScript, a CSS approach, a linter and separate environments. Job descriptions list them by name, and much day-to-day time goes into using them well.

How it differs: a backend program usually runs as written on a server you control. Frontend code must be transformed, bundled and optimised to run in many different browsers you don't control, so the toolchain is a bigger part of the frontend job.

Time: reading about 2 hours · practice (the Try it tasks) about 3 hours · assignment about 3 to 4 hours.

Lessons

  1. 1What build tools doReading 15–25 minutes, plus practice✓
  2. 2TypeScript for components and dataReading 15–25 minutes, plus practice✓
  3. 3Tailwind CSS and design tokensReading 15–25 minutes, plus practice✓
  4. 4Linting, formatting and code checksReading 15–25 minutes, plus practice✓
  5. 5Environments, configuration and error monitoringReading 15–25 minutes, plus practice✓

🛠️Assignment: A professional set-up for Kirana Express

This sets up the toolchain used by all three path projects.

  1. Move the project to Vite (or confirm your framework's build), and check the production build with a preview before deploying.
  2. Convert key components and API calls to strict TypeScript, with runtime validation for API data.
  3. Define design tokens and build Button and Card components that use only tokens.
  4. Add Prettier, ESLint with react-hooks and jsx-a11y rules, a type check and a pre-commit hook.
  5. Set up environments with safe variables, an .env.example, and error monitoring with source maps.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

What does a modern frontend toolkit do, and how do you use it safely?

Show a good answer

A good answer mentions: build tools that serve, transform, bundle and optimise code, with the production build tested before release; strict TypeScript for props and data plus runtime validation of API responses, avoiding any; design tokens with Tailwind or another CSS approach, and components instead of repeated classes or raw values; Prettier, ESLint (hooks and accessibility rules) and type checks in the editor, before commit and in CI; and environments configured with public-prefixed variables only for non-secrets, .env files kept out of Git, source maps and error monitoring without personal data.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. An app works with npm run dev, but the deployed version is a blank page. The console says a JavaScript file isn't found. The app is deployed under /admin/. What's wrong?

Why each option is right or wrong

  • “The server needs more memory” (Incorrect): Missing files point to paths, not server resources.
  • “React doesn't support subfolders” (Incorrect): React apps can be served from any path when built for it.
  • “The browser cached an old version” (Incorrect): A cache issue wouldn't explain files missing at a consistent path.
  • “The build's base path” is correct.

    The production build expects to be served from the site root, so it requests files from the wrong place. Setting the base path to /admin/ and testing with npm run preview fixes it.

    • Vite: the base option.
    • Habit: preview every production build.

📖 Revise: Lesson 1: What build tools do

Question ID sp-frontend-07-q1 · Report a mistake in this question
2. A team's old Webpack config takes 48 seconds to start and nobody understands its 310 lines. What's a sensible approach?

Why each option is right or wrong

  • “Keep it; build tools don't matter to users” (Incorrect): Slow tooling slows every change the team makes.
  • “Delete the config and hope defaults work” (Incorrect): Removing it without a plan could break the production build.
  • “Rewrite the whole app in a new framework” (Incorrect): The problem is the tooling, not the app's code.
  • “Move to Vite and check the build's output” is correct.

    A modern tool starts in seconds with a small config. Checking the production build and clicking through before switching keeps users safe while the team gets faster feedback.

    • Compare: bundle sizes before and after.
    • Keep: the old config in Git history for reference.

📖 Revise: Lesson 1: What build tools do

Question ID sp-frontend-07-q2 · Report a mistake in this question
3. An API sometimes returns price as a string, and price + deliveryFee shows "120.0030". The code is in TypeScript with price: number. Why didn't TypeScript catch it?

Why each option is right or wrong

  • “TypeScript doesn't support numbers” (Incorrect): TypeScript has a number type; the issue is runtime data.
  • “The developer forgot to save the file” (Incorrect): The type was written; the server's data didn't match it.
  • “Strings and numbers are the same in TypeScript” (Incorrect): TypeScript treats them as different types.
  • “Types don't check data at runtime” is correct.

    TypeScript checks your code, but types are removed when it runs, so a string from the server passes through. Validating responses with a schema such as Zod catches bad data at the boundary.

    • Derive: the type from the schema.
    • Report: bad records to the backend team.

📖 Revise: Lesson 2: TypeScript for components and data

Question ID sp-frontend-07-q3 · Report a mistake in this question
4. A developer used as any to silence an error. Later, orders fail for customers without a saved address. What should change?

Why each option is right or wrong

  • “Add more any so similar errors stop appearing” (Incorrect): That hides more bugs from the checker.
  • “Turn off strict mode” (Incorrect): Strict mode is what catches missing values like this.
  • “Require every customer to enter an address at sign-up” (Incorrect): That may help, but the code still assumes something that can be missing.
  • “Remove any; handle the missing address” is correct.

    The type checker was warning that address can be missing. Handling that case, such as asking for an address, fixes the bug, and a lint rule against any prevents repeats.

    • Use: unknown and narrowing when the type is unclear.
    • Test: a customer with no saved address.

📖 Revise: Lesson 2: TypeScript for components and data

Question ID sp-frontend-07-q4 · Report a mistake in this question
5. Three "primary" buttons use bg-[#16a34a], bg-green-600 and bg-emerald-600. Dark mode is coming. What should you do?

Why each option is right or wrong

  • “Add a dark-mode class to each button separately” (Incorrect): Each would need its own fix, and they'd still differ.
  • “Choose one at random and copy it to the others” (Incorrect): It may fix this page but doesn't prevent new variations.
  • “Remove Tailwind from the project” (Incorrect): The problem is inconsistent values, not the tool.
  • “One Button component using a token” is correct.

    A Button with a primary variant using brand-600 makes every primary button match. Dark mode and rebrands then change the token in one place.

    • Lint: warn about arbitrary colour values.
    • Check: contrast in both themes.

📖 Revise: Lesson 3: Tailwind CSS and design tokens

Question ID sp-frontend-07-q5 · Report a mistake in this question
6. Pull requests are full of comments about spacing and quotes, slowing merges. What's the fix?

Why each option is right or wrong

  • “A longer style guide document” (Incorrect): People still interpret and forget written rules.
  • “Ban comments on pull requests” (Incorrect): Comments on design and bugs are valuable.
  • “Let each developer use their own style” (Incorrect): Mixed styles make diffs noisy and reviews harder.
  • “A shared formatter, checked in CI” is correct.

    Prettier formats code automatically, so style stops being a review topic. Formatting the codebase once and checking it on every pull request keeps it consistent.

    • Run: in the editor and before commit too.
    • Reviews: focus on design and behaviour.

📖 Revise: Lesson 4: Linting, formatting and code checks

Question ID sp-frontend-07-q6 · Report a mistake in this question
7. Adding react-hooks/exhaustive-deps reports a store picker effect missing storeId in its dependencies. Stock sometimes shows for the previous store. What's the link?

Why each option is right or wrong

  • “None; lint warnings are only about style” (Incorrect): This rule finds real bugs, not style.
  • “The linter is wrong and should be disabled” (Incorrect): The warning explains the bug exactly.
  • “The store picker needs a key” (Incorrect): Keys reset components; the effect's dependencies are the issue.
  • “The effect doesn't rerun when the store changes” is correct.

    Without storeId in its dependencies, the effect can keep using the old store's value. Adding it (with a clean-up that cancels old requests) makes stock follow the selected store.

    • Rule: list everything the effect reads.
    • Test: switch stores quickly.

📖 Revise: Lesson 4: Linting, formatting and code checks

Question ID sp-frontend-07-q7 · Report a mistake in this question
8. A developer committed a .env file containing an API key to a public repository, then deleted it. Is it safe now?

Why each option is right or wrong

  • “Yes; the file is gone” (Incorrect): The key is still in Git history, which anyone can read.
  • “Yes, if the repository is made private later” (Incorrect): Others may already have copied it.
  • “No; delete the repository and start again” (Incorrect): That loses history and doesn't make the leaked key safe.
  • “No; rotate the key and keep .env out of Git” is correct.

    Deleting a file doesn't remove it from history, so the key must be treated as exposed. Rotating it makes the old key useless; .gitignore and an .env.example prevent a repeat.

    • Turn on: secret scanning for the repository.
    • Check: other places the key was used.

📖 Revise: Lesson 5: Environments, configuration and error monitoring

Question ID sp-frontend-07-q8 · Report a mistake in this question
9. A frontend needs a payment gateway's public key ID and its secret. Which can go in a VITE_ variable?

Why each option is right or wrong

  • “Both, since the build hides them” (Incorrect): Anything in browser code can be read by users.
  • “Neither; payment needs no frontend config” (Incorrect): Gateways usually need a public key ID in the browser to open checkout.
  • “Only the secret, because it's more important” (Incorrect): The secret must stay on the server.
  • “Only the public key ID” is correct.

    Variables with the VITE_ prefix end up in browser code. The public key ID is designed to be visible; the secret stays in server-only configuration.

    • Secret calls: made by your backend.
    • Review: every public-prefixed variable.

📖 Revise: Lesson 5: Environments, configuration and error monitoring

Question ID sp-frontend-07-q9 · Report a mistake in this question
10. After a release, error monitoring shows a new error from 2% of checkout visits, but the stack trace is minified and unreadable. What's missing?

Why each option is right or wrong

  • “More logging in the browser console” (Incorrect): Users' consoles aren't visible to you.
  • “A slower build that doesn't minify” (Incorrect): Users would download larger files; source maps solve it without that cost.
  • “Asking affected users to describe the error” (Incorrect): Descriptions help, but the exact line comes from source maps.
  • “Source maps uploaded for that release” is correct.

    Source maps translate minified code back to your files and lines. Uploading them to the monitoring tool for each release makes the stack trace readable without publishing your source.

    • Version: each release, so errors map correctly.
    • Avoid: sending personal data in reports.

📖 Revise: Lesson 5: Environments, configuration and error monitoring

Question ID sp-frontend-07-q10 · Report a mistake in this question

ProLearners Assist