uniweb 0.12.49 → 0.12.50

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.12.49",
+  "version": "0.12.50",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,12 +41,12 @@
     "js-yaml": "^4.1.0",
     "prompts": "^2.4.2",
     "tar": "^7.0.0",
-    "@uniweb/core": "0.7.20",
     "@uniweb/kit": "0.9.24",
-    "@uniweb/runtime": "0.8.26"
+    "@uniweb/runtime": "0.8.26",
+    "@uniweb/core": "0.7.20"
   },
   "peerDependencies": {
-    "@uniweb/build": "0.14.31",
+    "@uniweb/build": "0.14.32",
     "@uniweb/content-reader": "1.1.12",
     "@uniweb/semantic-parser": "1.1.17"
   },

package/src/commands/add.js

@@ -1158,6 +1158,7 @@ async function addCi(rootDir, opts, pm = 'pnpm') {
   // project's floor, raised if that pnpm needs more.
   const pnpmVersion = resolveCiPnpmVersion(rootPkg)
   const nodeVersion = resolveCiNodeVersion(rootPkg.engines?.node, pm, pnpmVersion)
+  reportCiToolchain({ pm, pnpmVersion, nodeVersion, rootPkg })
 
   const siteDir = join(rootDir, site.path)
   if (!resolvedDomain) {
@@ -1282,6 +1283,23 @@ function stripScope(name) {
   return name.startsWith('@') ? name.split('/').pop() : name
 }
 
+/**
+ * Print the toolchain the generated workflow will install.
+ *
+ * These versions are inferred whenever the project doesn't state them, and a
+ * silent inference is exactly what let a wrong pnpm/Node pairing ship
+ * unnoticed. Showing what resolved — and how to override it — follows the
+ * same "resolve, then show what resolved" rule the publish scope picker uses.
+ */
+function reportCiToolchain({ pm, pnpmVersion, nodeVersion, rootPkg }) {
+  const declared = typeof rootPkg?.packageManager === 'string'
+  const tool = pm === 'pnpm' ? `pnpm ${pnpmVersion}` : pm === 'yarn' ? 'yarn' : 'npm'
+  info(`CI will use ${tool} + Node ${nodeVersion}${declared ? '' : ' (inferred)'}`)
+  if (!declared && pm === 'pnpm') {
+    info(`Pin with "packageManager": "pnpm@<version>" in package.json to use a different major.`)
+  }
+}
+
 /**
  * Write scaffolded CI files. Refuses to overwrite without --force so
  * re-running doesn't silently clobber edits the user made to a workflow.
@@ -1342,6 +1360,7 @@ async function addFoundationCi(rootDir, opts, adapter, pm) {
   // project's floor, raised if that pnpm needs more.
   const pnpmVersion = resolveCiPnpmVersion(rootPkg)
   const nodeVersion = resolveCiNodeVersion(rootPkg.engines?.node, pm, pnpmVersion)
+  reportCiToolchain({ pm, pnpmVersion, nodeVersion, rootPkg })
 
   let result
   try {

package/src/framework-index.json

@@ -1,9 +1,9 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-07-21T21:33:51.867Z",
+  "generatedAt": "2026-07-21T21:54:20.384Z",
   "packages": {
     "@uniweb/build": {
-      "version": "0.14.31",
+      "version": "0.14.32",
       "path": "framework/build",
       "deps": [
         "@uniweb/content-reader",
@@ -99,7 +99,7 @@
       "deps": []
     },
     "@uniweb/unipress": {
-      "version": "0.4.38",
+      "version": "0.4.39",
       "path": "framework/unipress",
       "deps": [
         "@uniweb/build",

package/src/versions.js

@@ -56,28 +56,32 @@ export const REACT_VERSION = '^19.0.0'
  * Default pnpm major for generated CI, used only when the project does not
  * say which pnpm it uses (see `resolveCiPnpmVersion`).
  *
- * **This is deliberately 10, not the newest release.** CI must run the same
- * toolchain the developer runs, or it reports failures that have nothing to
- * do with their code. Pinning 11 while projects were on 10 produced exactly
- * that, twice over, on a real repo:
+ * **Tracks the current stable major.** `pnpm@latest` is 11.x, so a developer
+ * running `npm i -g pnpm` today gets 11 — and CI should run what they run.
+ * Both of pnpm 11's install-time policies are handled:
  *
- *   - pnpm 11 refuses any dependency published in the last 24 hours
- *     (`ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION`). Publish a package and its
- *     consumer's CI fails until the next day.
- *   - pnpm 11 changed build-script approval: `onlyBuiltDependencies` in
- *     `pnpm-workspace.yaml` no longer suffices, and the install exits 1 with
- *     `ERR_PNPM_IGNORED_BUILDS`. Uniweb sites use `sharp` for image
- *     processing, so this breaks essentially every site's first CI run.
+ *   - Build-script approval. pnpm 11 renamed `onlyBuiltDependencies` (list)
+ *     to `allowBuilds` (map) and ignores the old name, so an unprepared
+ *     project fails with `ERR_PNPM_IGNORED_BUILDS`. The workspace template
+ *     emits both spellings, so scaffolds install on either major.
+ *   - Minimum release age. pnpm 11 refuses dependencies published in the
+ *     last 24 hours. Installing locally with pnpm 11 auto-collects the
+ *     needed `minimumReleaseAgeExclude` entries into `pnpm-workspace.yaml`,
+ *     and CI then honours them — verified end to end.
  *
- * Neither is a bug in pnpm — both are reasonable hardening. They are simply
- * not things a generated workflow should impose on a project that has not
- * opted into that major.
+ * **The one combination that breaks is installing locally with pnpm 10 while
+ * CI runs 11**: pnpm 10 never writes those exclude entries, so CI rejects any
+ * dependency in the lockfile published within the last day — including
+ * unrelated transitive ones. A project still on pnpm 10 should say so with
+ * `"packageManager": "pnpm@10.x.y"`, which `resolveCiPnpmVersion` honours and
+ * which pins CI to match. `uniweb add ci` prints the resolved toolchain so
+ * that choice is visible rather than silent.
  *
  * A bare major installs the latest patch of that major at CI run time. Before
  * bumping this, check the new major's release notes for install-time policy
  * changes, and update `PNPM_MIN_NODE` in the same commit.
  */
-export const PNPM_VERSION = '10'
+export const PNPM_VERSION = '11'
 
 /**
  * Minimum Node major each supported pnpm major will run on, from that