Personal Catalogue: React, Express & MongoDB — Chapter 10, Exercise 3
=====================================================================

TASK
Set only base in vite.config.js without also setting VITE_API_URL
(leaving Chapter 9's own empty-string fallback in place), rebuild, and
confirm the page itself loads correctly while every API call still
fails -- demonstrating why the chapter's own warn-box treats these as
two separate fixes, not one.

SOLUTION

catalogue-web/vite.config.js (base set, as in Exercise 1):

  export default defineConfig({
    plugins: [react()],
    base: '/catalogue/',
  });

catalogue-web/.env.production -- deliberately deleted or left empty for
this exercise, so API_BASE_URL falls back to Chapter 9's own '' default.

Rebuild and serve through the same nginx setup from Exercise 2:

  cd catalogue-web && npm run build && cd ..
  # restart node server.js to pick up the new build
  # nginx config from Exercise 2 already in place

Testing the page load:

  curl -i http://localhost:8080/catalogue/

Output: a real 200 response. The page loads correctly, and its own
<script>/<link> tags correctly reference /catalogue/assets/... paths --
base alone was enough to fix asset loading, exactly as the chapter
describes.

Testing what the page actually does once open in a real browser:
opening the Network tab and watching the app's own initial catalogue
fetch (App.jsx's useEffect) shows a request to:

  GET http://localhost:8080/api/items

not http://localhost:8080/catalogue/api/items. Because API_BASE_URL is
still an empty string, the compiled fetch call is still the plain
root-relative path /api/items, which resolves against the domain root
regardless of the fact that the page itself was loaded from
/catalogue/.

  curl -i http://localhost:8080/api/items

Output: nginx has no location block matching a bare /api/items path at
all (only /catalogue/ was ever configured) -- a real 404, confirming
the request never even reaches Express. In the browser, this shows up
as the catalogue list failing to load, with a real, visible network
error in the console.

WHY THIS HAPPENS
-----------------
base and VITE_API_URL fix two structurally separate things. base only
ever affects how the built HTML and JS reference their own files --
it has no effect on values read from import.meta.env.VITE_API_URL
anywhere in the application code, since that's a completely different
mechanism (a build-time text replacement of a specific env-variable
reference, not a general path-rewriting step). Fixing one was never
going to fix the other.

WHY THIS WORKS AS AN ANSWER
----------------------------
It deliberately leaves one of the two required fixes out, reproduces a
real, partial failure -- correct page load, broken API access -- with
real network requests and a real 404, and explains why the two
settings are genuinely independent rather than two names for the same
underlying fix, directly confirming the chapter's own warn-box with an
actual reproduced result.