learning-website-nextjs1-1  Exercise 3: Prove the Sharing, and Find Its Cost
==============================================================================

Two questions a monorepo has to answer: does the shared package really stay in step with the
Django project, and what happens to the other apps when it changes?

Part A: is it the same site map? A one-off script runs the Python site map, prints it as JSON and
compares it with the TypeScript one, key by key.

Save as compare-sitemap.mjs:

// one-off check: the TypeScript site map equals the Django project's Python one
import { execFileSync } from "node:child_process";
import { SITES, SIDEBAR_ROUTES, SPECIAL_PREFIXES } from "./packages/sites/src/index.ts";
import assert from "node:assert/strict";
const py = JSON.parse(execFileSync("C:/lwdj/v/Scripts/python.exe", ["-c",
  "import json,sys;sys.path.insert(0,'C:/lwdj/proj');from config.sites_config import SITES,SIDEBAR_ROUTES,SPECIAL_PREFIXES;print(json.dumps([SITES,SIDEBAR_ROUTES,SPECIAL_PREFIXES]))"]).toString());
assert.deepEqual(JSON.parse(JSON.stringify(SITES)), py[0]);
assert.deepEqual(SIDEBAR_ROUTES, py[1]);
assert.deepEqual(SPECIAL_PREFIXES, py[2]);
console.log("TypeScript and Python site maps are identical:", Object.keys(SITES).length, "sites,", Object.values(SITES).reduce((n, s) => n + s.folders.length, 0), "folders");

  node compare-sitemap.mjs
  TypeScript and Python site maps are identical: 8 sites, 48 folders

So there are two copies of the site map (Python and TypeScript), and this script is what keeps them
honest. It is not part of "npm test", because it needs the Django project and a Python on the machine.
That is a weakness: two sources of truth that a person has to remember to compare. In the final site
only ONE framework would be used, which removes it.

Part B: what a change to the shared package does. I changed the title "Languages" to
"Languages (changed)" in packages/sites/src/index.ts, then:

  npm run build:languages
  languages build output contains "Languages (changed)":            yes
  webdevelopment (NOT rebuilt) contains "Languages (changed)":      no  (0 matches)

then changed it back and ran "npm run build": all three apps now contain 0 matches.

The lesson: a shared package is shared SOURCE, not a running service. A change reaches an app only
when that app is rebuilt, so after changing the package EVERY app that uses it must be rebuilt and
redeployed, or the sites disagree. With three apps that is a command (npm run build, 18.6 s); with
eight, extrapolating from 18.6 s for three, roughly 50 s (an estimate, not measured), and a tool such as Turborepo can skip the apps a change
cannot affect. Turborepo was NOT used or run here: this is a description of what it is for, not
a tested recommendation.

Part C: the choices that were made, and what was not tried.
- npm workspaces, not pnpm or Yarn: nothing extra to install; pnpm would use much less disk
  (npm installed 369 MB of node_modules); pnpm was not run.
- Three apps (portfolio, languages, webdevelopment), not eight: the other five would be copies of
  languages with a different name and port, and are added the same way.
- One app per site, not one app that looks at the host name: that choice (Chapter 2) is the reason
  every build and every failure stays separate; the cost is eight deployments instead of one.

WHY THIS WORKS AS AN ANSWER
---------------------------
It measures the one claim a monorepo makes ("one change, every site") and finds its price (every app
must be rebuilt), instead of stopping at the demonstration that it builds.