@koehler8/cms 1.3.1 → 1.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,46 @@
1
1
  # Changelog
2
2
 
3
+ ## 1.4.0
4
+
5
+ ### Changed
6
+
7
+ - **The bundled Pinia is now 4.x (was 3.x).** `createPinia()` runs Pinia 4.0.3
8
+ and that is the instance handed to every extension through
9
+ `runExtensionSetups({ app, router, pinia, ... })`.
10
+
11
+ **If you maintain an extension that declares `peerDependencies.pinia`, widen
12
+ it to admit `^4`** — for example `"pinia": "^3.0.0 || ^4.0.0"`. An extension
13
+ pinned to `^3` will fail to install alongside this release.
14
+ (`@koehler8/cms-ext-crypto` 1.0.0-beta.4 is in exactly that position; it is
15
+ not installed on any site in the fleet.)
16
+
17
+ Nothing else about extensions changes: the instance is still a single Pinia
18
+ per site — this package deliberately excludes `vue`, `vue-router` and `pinia`
19
+ from Vite's dependency pre-bundling so a linked extension cannot end up with
20
+ a second copy — and `vue-router` 5.3.1 already accepts `pinia@4`
21
+ (`^3.0.4 || ^4.0.2`).
22
+
23
+ Two consequences worth knowing, neither of which needs action in a site:
24
+
25
+ - Pinia 4 makes `@vue/devtools-api` a **required peer** at `^8.1.5`, where
26
+ Pinia 3 carried it as a dependency. npm installs it automatically; on a
27
+ consumer site the resolved version moves 7.x → 8.x, which also lets
28
+ `vue-router`'s own nested copies collapse into the hoisted one. In this
29
+ repo that made the lockfile *smaller* (318 → 307 entries).
30
+ - Pinia 4 is ESM-only and depends on `nostics`. That package was already
31
+ present in this tree, so no new package enters a site's dependency graph.
32
+
33
+ No framework source change was needed: this package defines no store of its
34
+ own and uses none of the APIs Pinia changed.
35
+
36
+ ### Internal (not shipped)
37
+
38
+ - Dev dependency `vitest` 4.1.11 → 5.0.1 (with `@vitest/coverage-v8`). This
39
+ restores the repo's ability to regenerate its own `package-lock.json` under
40
+ npm 10: on `vitest` 4.1.x a fresh `npm install` died in arborist with
41
+ `Cannot read properties of null (reading 'edgesOut')`, and only the existing
42
+ lockfile kept the repo installable. Neither package ships.
43
+
3
44
  ## 1.3.1
4
45
 
5
46
  ### Fixed
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@koehler8/cms",
3
- "version": "1.3.1",
3
+ "version": "1.4.0",
4
4
  "description": "Vertex CMS — lightweight, config-driven Vue 3 framework with theming, extensions, and SSG support",
5
5
  "license": "MIT",
6
6
  "type": "module",
@@ -80,7 +80,7 @@
80
80
  "@unhead/vue": "^2.1.15",
81
81
  "ajv": "^8.20.0",
82
82
  "ajv-formats": "^3.0.1",
83
- "pinia": "^3.0.1",
83
+ "pinia": "^4.0.3",
84
84
  "sharp": "^0.35.3"
85
85
  },
86
86
  "optionalDependencies": {
@@ -90,11 +90,11 @@
90
90
  },
91
91
  "devDependencies": {
92
92
  "@vitejs/plugin-vue": "^6.0.8",
93
- "@vitest/coverage-v8": "^4.1.11",
94
- "@vue/test-utils": "^2.4.10",
93
+ "@vitest/coverage-v8": "^5.0.1",
94
+ "@vue/test-utils": "^2.5.1",
95
95
  "happy-dom": "^20.9.0",
96
96
  "vite": "^8.3.0",
97
- "vitest": "^4.1.11",
97
+ "vitest": "^5.0.1",
98
98
  "vue": "^3.5.43",
99
99
  "vue-router": "^5.3.1"
100
100
  },
@@ -1 +1 @@
1
- 20.19.0
1
+ 22.23.2
@@ -89,14 +89,14 @@ Edit `themes/<slug>/theme.config.js`. The CMS regenerates `virtual:cms-theme-var
89
89
 
90
90
  ## Lockfile and npm version — read before bumping any dep
91
91
 
92
- 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.
92
+ 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.
93
93
 
94
94
  Two failure modes seen on sister sites:
95
95
  1. `Cannot find module '@rolldown/binding-linux-x64-gnu'` — npm 11 regen stripped optional-dep entries Amplify needs.
96
96
  2. `npm ci ... Missing: @types/react@..., @noble/hashes@... from lock file` — npm 11 omitted entries npm 10 expects.
97
97
 
98
98
  Rules:
99
- - **Always run `nvm use` before `npm install`**. `.nvmrc` pins 20.19.0 (which ships npm 10.8.x).
99
+ - **Always run `nvm use` before `npm install`**. `.nvmrc` pins 22.23.2 (which ships npm 10.9.x).
100
100
  - **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.
101
101
  - **The build uses `npm install`**, not `npm ci` (see `amplify.yml`) for drift tolerance.
102
102
 
@@ -7,7 +7,7 @@ For architecture, conventions, and a navigation guide for "where things go" (con
7
7
  ## Local development
8
8
 
9
9
  ```bash
10
- nvm use # Node 20.19.0 per .nvmrc
10
+ nvm use # Node 22.23.2 per .nvmrc
11
11
  cp .env.example .env
12
12
  npm install
13
13
  npm run dev
@@ -3,7 +3,7 @@ frontend:
3
3
  phases:
4
4
  preBuild:
5
5
  commands:
6
- - nvm install 20.19.0 && nvm use 20.19.0
6
+ - nvm install 22.23.2 && nvm use 22.23.2
7
7
  # Use `npm install` (not `npm ci`) so the build tolerates
8
8
  # lockfile/npm-version drift. See CLAUDE.md → "Lockfile and
9
9
  # npm version" for the rationale.