Challenge 3: Three Distinct Jobs Worth Keeping Separate — Possible Solution
====================================================================

THE THREE JOBS
------------------------------
Per this chapter's own explanation:

1. Bundling — combining many files into fewer files, automatically
   resolving the dependency graph (full treatment in Chapter 2).
2. Transpiling — converting modern JavaScript or TypeScript syntax
   into a form older browsers can understand (full treatment in
   Chapter 4).
3. Minifying — stripping whitespace, shortening variable names, and
   removing dead code to shrink the production output (full treatment
   in Chapter 8).

WHY THEY'RE WORTH TREATING AS SEPARATE CONCERNS
------------------------------
Each job solves a genuinely different problem, with a genuinely
different cause:

- Bundling exists because of HOW MANY files a project has and how
  they depend on each other — a purely structural/organizational
  problem.
- Transpiling exists because of WHICH JAVASCRIPT/TYPESCRIPT SYNTAX is
  used versus what a target browser actually supports — a language-
  compatibility problem, unrelated to how many files exist.
- Minifying exists because of FILE SIZE and production performance —
  a distribution/optimization problem, unrelated to either file count
  or language syntax.

A project could in principle need any one of these without the
others: a single-file project written in plain, already-widely-
supported JavaScript needs no bundling and no transpiling, but might
still benefit from minification before shipping. A multi-file project
using only long-supported syntax needs bundling but no transpiling.
Keeping the three ideas conceptually separate makes it possible to
reason about which SPECIFIC tool or setting is responsible when
something in a build breaks, rather than treating "the build" as one
undifferentiated black box.

WHY THIS MATTERS EVEN THOUGH ONE TOOL OFTEN DOES ALL THREE
------------------------------
Real tools (Webpack, Vite, esbuild) commonly perform all three jobs
together in one configured pipeline, which is precisely why it's easy
to blur them into a single mental category. But per this chapter's
own framing, later chapters (2, 4, and 8) each dedicate themselves to
exactly one of these jobs specifically because they're solved by
different mechanisms and different historical tools — understanding
them as three separable jobs makes each of those later chapters'
own narrower focus make sense, rather than each one feeling like an
arbitrary subset of "build stuff."

WHY THIS WORKS AS AN ANSWER
------------------------------
It lists the three jobs accurately from the chapter's own text, and
explains the conceptual separation using each job's own distinct root
cause, plus the practical benefit (being able to reason about which
specific piece of a build pipeline is responsible for a given
problem) rather than just repeating that they're "different things."