Romaji to Kana Converter: React & Next.js — Chapter 7, Exercise 1
=====================================================================

TASK
This chapter measured a real ~22.7x reduction in node_modules size
using the standalone output mode (432MB full vs. 19MB pruned).
Explain, in your own words, why a real production install of this
project's own future Redis client (Chapter 6) would make this
pruning step matter even more than it already does for the app as it
stands today.

SOLUTION

The full 432MB node_modules figure measured in this chapter includes
every package the project depends on for development and build
tooling too -- TypeScript, ESLint, Next.js's own build-time
dependencies, type definitions, and so on -- none of which are ever
actually needed once the app is running in production. The pruned
19MB standalone folder only keeps what next build's own file tracing
determined the running server genuinely touches at request time.

Adding Chapter 6's own Redis client (ioredis, the package this course
actually benchmarked with) to the project doesn't change that
principle -- it adds one more real, used-at-runtime dependency, which
the standalone tracer would correctly keep in the pruned output,
exactly the way it already keeps Next.js's own server runtime. What
it changes is the size of the *avoidable* portion. A full,
un-pruned node_modules install carries every dev-only tool at its own
full size regardless of whether the app that ships alongside it is
small or large -- so as the project's own real dependency list grows
(a Redis client now, possibly more later), the absolute megabytes
wasted by shipping the entire dev-time install rather than the traced
subset only grows too. The ~22.7x ratio measured in this chapter
isn't a fixed number -- it's the current project's own ratio of
"stuff only needed to build it" to "stuff needed to actually run it."
Every dependency added specifically for a real runtime need (like
ioredis) nudges that ratio further in the pruned build's own favor,
since it adds real weight to the side that was already smaller.

WHY THIS WORKS AS AN ANSWER
----------------------------
It correctly identifies that the ~22.7x figure is a ratio between
dev-time-only weight and genuine runtime weight, not a fixed constant,
and explains that adding a real runtime dependency like a Redis
client doesn't shrink the pruning step's own value -- it grows the
gap between "what a full install carries" and "what the app actually
needs," since dev tooling stays the same size regardless.