@koehler8/cms 1.3.1 → 1.4.1

package/CHANGELOG.md

@@ -1,5 +1,82 @@
 # Changelog
 
+## 1.4.1
+
+### Fixed
+
+- **The embedded config payload is now actually used on locale-prefixed routes.**
+  vite-ssg runs the setup fn *before* `app.use(router)`, so `router.currentRoute`
+  is still `START_LOCATION` (`'/'`, `params: {}`) there — identically on every
+  page. During SSG that was already handled, because vite-ssg hands the route
+  over on `ctx.routePath`. On the **client** it calls the setup fn with no
+  argument at all, so there was nothing to resolve and the code fell through to
+  `START_LOCATION`.
+
+  `loadSiteConfig` derives its cache key from `params.locale`, so the key came
+  out `'default'` on every client page while the SSG had stamped the real locale
+  on `siteConfigLocale`. On a locale-prefixed route the two never matched, so
+  `primeConfigSync` was skipped, `hydrateFromSyncCache` missed, and the client
+  discarded the payload it had just been served and awaited a full config load
+  **inside the setup fn, on the critical path, before mount** — the exact
+  regression the priming machinery exists to prevent.
+
+  Measured on a multi-locale site, same machine and build, only this patch
+  differing. First config chunk on a `/th/` piece page: **44 ms before**
+  (DOMContentLoaded 34 ms — on the critical path), **1364 ms after** (deferred
+  to `requestIdleCallback`, as designed). The load is *deferred, not removed*:
+  `trimConfigToPage` stamps `pagesPartial` on every page, so the idle reload
+  still runs.
+
+  ⚠️ A cross-environment comparison hides this completely. A production bundle
+  that needs ~1.4 s to download and execute shows its config chunks at ~1607 ms,
+  which *looks* deferred when it is in fact immediate. Only a same-environment
+  A/B separates the two.
+
+  **No action needed in a site.** Single-locale sites already stamped `default`
+  and primed correctly, so their behaviour is unchanged; multi-locale sites gain
+  the deferral.
+
+## 1.4.0
+
+### Changed
+
+- **The bundled Pinia is now 4.x (was 3.x).** `createPinia()` runs Pinia 4.0.3
+  and that is the instance handed to every extension through
+  `runExtensionSetups({ app, router, pinia, ... })`.
+
+  **If you maintain an extension that declares `peerDependencies.pinia`, widen
+  it to admit `^4`** — for example `"pinia": "^3.0.0 || ^4.0.0"`. An extension
+  pinned to `^3` will fail to install alongside this release.
+  (`@koehler8/cms-ext-crypto` 1.0.0-beta.4 is in exactly that position; it is
+  not installed on any site in the fleet.)
+
+  Nothing else about extensions changes: the instance is still a single Pinia
+  per site — this package deliberately excludes `vue`, `vue-router` and `pinia`
+  from Vite's dependency pre-bundling so a linked extension cannot end up with
+  a second copy — and `vue-router` 5.3.1 already accepts `pinia@4`
+  (`^3.0.4 || ^4.0.2`).
+
+  Two consequences worth knowing, neither of which needs action in a site:
+
+  - Pinia 4 makes `@vue/devtools-api` a **required peer** at `^8.1.5`, where
+    Pinia 3 carried it as a dependency. npm installs it automatically; on a
+    consumer site the resolved version moves 7.x → 8.x, which also lets
+    `vue-router`'s own nested copies collapse into the hoisted one. In this
+    repo that made the lockfile *smaller* (318 → 307 entries).
+  - Pinia 4 is ESM-only and depends on `nostics`. That package was already
+    present in this tree, so no new package enters a site's dependency graph.
+
+  No framework source change was needed: this package defines no store of its
+  own and uses none of the APIs Pinia changed.
+
+### Internal (not shipped)
+
+- Dev dependency `vitest` 4.1.11 → 5.0.1 (with `@vitest/coverage-v8`). This
+  restores the repo's ability to regenerate its own `package-lock.json` under
+  npm 10: on `vitest` 4.1.x a fresh `npm install` died in arborist with
+  `Cannot read properties of null (reading 'edgesOut')`, and only the existing
+  lockfile kept the repo installable. Neither package ships.
+
 ## 1.3.1
 
 ### Fixed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@koehler8/cms",
-  "version": "1.3.1",
+  "version": "1.4.1",
   "description": "Vertex CMS — lightweight, config-driven Vue 3 framework with theming, extensions, and SSG support",
   "license": "MIT",
   "type": "module",
@@ -80,7 +80,7 @@
     "@unhead/vue": "^2.1.15",
     "ajv": "^8.20.0",
     "ajv-formats": "^3.0.1",
-    "pinia": "^3.0.1",
+    "pinia": "^4.0.3",
     "sharp": "^0.35.3"
   },
   "optionalDependencies": {
@@ -90,11 +90,11 @@
   },
   "devDependencies": {
     "@vitejs/plugin-vue": "^6.0.8",
-    "@vitest/coverage-v8": "^4.1.11",
-    "@vue/test-utils": "^2.4.10",
+    "@vitest/coverage-v8": "^5.0.1",
+    "@vue/test-utils": "^2.5.1",
     "happy-dom": "^20.9.0",
     "vite": "^8.3.0",
-    "vitest": "^4.1.11",
+    "vitest": "^5.0.1",
     "vue": "^3.5.43",
     "vue-router": "^5.3.1"
   },

package/src/main.js

@@ -8,6 +8,7 @@ import { routes, resolveHistory, applyRouterGuards } from './router/index.js';
 import { shouldEnableAnalytics, scheduleAnalyticsLoad, configureAnalyticsConsentMode } from './utils/cookieConsent.js';
 import { loadConfigData, primeConfigSync, trimConfigToPage, resolvePageIdForRoute } from './utils/loadConfig.js';
 import { applyInitialStateTrims } from './utils/initialStateTrim.js';
+import { currentRouteHref } from './utils/currentRoute.js';
 import { persistAttributionFromLocation } from './utils/trackingContext.js';
 import { applyThemeVariables } from './themes/themeManager.js';
 import { setActiveThemeKey } from './utils/themeColors.js';
@@ -136,19 +137,22 @@ export function createCmsApp() {
       };
 
       const extractCurrentRoute = () => {
-        // During SSG, vite-ssg passes the route being pre-rendered as a string
-        // on `ctx.routePath` and only pushes the router AFTER this setup fn runs
-        // — so `router.currentRoute` is still vue-router's START_LOCATION ('/')
-        // here, identically on every page. Resolve `routePath` through the router
-        // (a pure match, no navigation) to recover the real path + `params.locale`.
-        // Without this, `resolveCurrentPageId` sees '/' for every route, so the
-        // payload trim targets the wrong page — or, when '/' is ambiguous, none.
-        const routePath = ctx?.routePath;
-        if (typeof routePath === 'string' && routePath) {
+        // vite-ssg runs this setup fn BEFORE `app.use(router)`, so
+        // `router.currentRoute` is still vue-router's START_LOCATION ('/') here,
+        // identically on every page — during SSG *and* on the client. The href
+        // that IS authoritative differs per half (ctx.routePath vs the window's
+        // own location); currentRouteHref picks it, with the full account of why
+        // the client half is not optional. Resolve it through the router — a pure
+        // match, no navigation — to recover the real path + `params.locale`.
+        const href = currentRouteHref(
+          ctx,
+          typeof window !== 'undefined' ? window.location : null,
+        );
+        if (href) {
           try {
-            return router.resolve(routePath);
+            return router.resolve(href);
           } catch {
-            return { path: routePath, params: {} };
+            return { path: href, params: {} };
           }
         }
         if (ctx?.route) {

package/src/utils/currentRoute.js

@@ -0,0 +1,49 @@
+// Which href the app should resolve through the router to learn the route it is
+// actually on.
+//
+// Both halves of the lifecycle are blind to this in the same way, for the same
+// reason: vite-ssg runs the setup fn BEFORE `app.use(router)`, so
+// `router.currentRoute` is still vue-router's START_LOCATION ('/', `params: {}`)
+// — identically on every page.
+//
+//   - During SSG, vite-ssg hands the route being pre-rendered over as a string on
+//     `ctx.routePath`, so that is authoritative.
+//   - On the CLIENT it calls the setup fn with no argument at all: no
+//     `ctx.routePath`, no `ctx.route`. The only authoritative source left is the
+//     window's own location.
+//
+// Falling through to START_LOCATION on the client is not a cosmetic miss. The
+// config cache key is derived from `params.locale`, so it came out 'default' on
+// every page while the SSG had stamped the real locale on `siteConfigLocale`.
+// The two never matched on a locale-prefixed route, `primeConfigSync` was
+// skipped, and the client discarded the embedded payload and re-fetched the
+// whole config tree on the critical path — the exact regression the priming
+// machinery exists to prevent. Measured on sparkbang.com/th/<piece>/ before the
+// fix: 151 JS requests / 405 KB, 112 of them per-piece config chunks, while the
+// 17 KB embedded payload was parsed and thrown away.
+//
+// Pure and dependency-free so the fall-through can be pinned by a unit test;
+// `main.js` owns the router.resolve() call itself (a pure match, no navigation).
+//
+// Returns null when the caller should use `ctx.route` as-is, or when there is
+// nothing authoritative to resolve and START_LOCATION is genuinely all there is.
+
+/**
+ * @param {{routePath?: unknown, route?: unknown}|null|undefined} ctx
+ *   The vite-ssg setup context. `routePath` is set during SSG only.
+ * @param {{pathname?: unknown, search?: unknown}|null|undefined} location
+ *   `window.location` on the client; omit/null on the server.
+ * @returns {string|null} the href to resolve, or null to fall back.
+ */
+export function currentRouteHref(ctx, location) {
+  const routePath = ctx?.routePath;
+  if (typeof routePath === 'string' && routePath) return routePath;
+  // A context that already carries a resolved route needs no href at all.
+  if (ctx?.route) return null;
+  const pathname = location?.pathname;
+  if (typeof pathname === 'string' && pathname) {
+    const search = typeof location?.search === 'string' ? location.search : '';
+    return `${pathname}${search}`;
+  }
+  return null;
+}

package/templates/scaffolds/site/.nvmrc

@@ -1 +1 @@
-20.19.0
+22.23.2

package/templates/scaffolds/site/CLAUDE.md

@@ -89,14 +89,14 @@ Edit `themes/<slug>/theme.config.js`. The CMS regenerates `virtual:cms-theme-var
 
 ## Lockfile and npm version — read before bumping any dep
 
-This project pins **Node 20.19 / npm 10.8** to match AWS Amplify exactly. Local installs with a different npm version produce subtly different lockfiles that look fine locally but break CI.
+This project pins **Node 22.23.2 / npm 10.9** to match AWS Amplify exactly (never 24 — it ships npm 11). Local installs with a different npm version produce subtly different lockfiles that look fine locally but break CI.
 
 Two failure modes seen on sister sites:
 1. `Cannot find module '@rolldown/binding-linux-x64-gnu'` — npm 11 regen stripped optional-dep entries Amplify needs.
 2. `npm ci ... Missing: @types/react@..., @noble/hashes@... from lock file` — npm 11 omitted entries npm 10 expects.
 
 Rules:
-- **Always run `nvm use` before `npm install`**. `.nvmrc` pins 20.19.0 (which ships npm 10.8.x).
+- **Always run `nvm use` before `npm install`**. `.nvmrc` pins 22.23.2 (which ships npm 10.9.x).
 - **Prefer targeted bumps**: `npm install <pkg>@<ver> --no-audit --no-fund`. **Never** `rm package-lock.json && npm install` unless you're on the pinned npm version.
 - **The build uses `npm install`**, not `npm ci` (see `amplify.yml`) for drift tolerance.
 

package/templates/scaffolds/site/README.md

@@ -7,7 +7,7 @@ For architecture, conventions, and a navigation guide for "where things go" (con
 ## Local development
 
 ```bash
-nvm use                    # Node 20.19.0 per .nvmrc
+nvm use                    # Node 22.23.2 per .nvmrc
 cp .env.example .env
 npm install
 npm run dev

package/templates/scaffolds/site/amplify.yml

@@ -3,7 +3,7 @@ frontend:
   phases:
     preBuild:
       commands:
-        - nvm install 20.19.0 && nvm use 20.19.0
+        - nvm install 22.23.2 && nvm use 22.23.2
         # Use `npm install` (not `npm ci`) so the build tolerates
         # lockfile/npm-version drift. See CLAUDE.md → "Lockfile and
         # npm version" for the rationale.