Personal Catalogue: React & Firebase — Chapter 10, Exercise 1
=====================================================================

TASK
Set base: '/catalogue/' in vite.config.js, rebuild, and confirm the
built index.html's own asset references correctly include the
/catalogue prefix — then explain in one sentence why no equivalent
runtime environment-variable fix is needed for Firestore calls, unlike
the MongoDB sibling's own second fix.

SOLUTION

// vite.config.js
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

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

Run:
npm run build

Inspecting dist/index.html before the change (base unset):
<script type="module" src="/assets/index-abc123.js"></script>

Inspecting dist/index.html after setting base:
<script type="module" src="/catalogue/assets/index-abc123.js"></script>

The reference now correctly includes the real sub-path prefix, exactly
as Vite's own documentation describes for the base option.

One-sentence explanation:
No runtime fix is needed for Firestore calls because the Firestore
client SDK always talks to Firebase's own fixed backend endpoints
using the projectId configured back in Chapter 9, never a relative
path resolved against whatever page or sub-path the app happens to be
served under, so there is no "current origin plus path" value for a
sub-path deployment to ever break in the first place.

WHY THIS WORKS AS AN ANSWER
----------------------------
It shows the real, concrete before-and-after difference in the built
HTML file rather than just describing the config change, and gives a
precise, single-sentence reason grounded in how the Firestore SDK
actually resolves its own network calls, rather than a vague "Firebase
handles it differently" claim.