@uniweb/unipress 0.4.20 → 0.4.22

package/README.md

@@ -40,7 +40,7 @@ Foundations consume [@uniweb/press](https://github.com/uniweb/press) for the byt
 brew install uniweb/unipress/unipress
 ```
 
-Updates land via `brew upgrade unipress`. The macOS binary is signed with the Proximify Inc. Developer ID and Apple-notarized — no Gatekeeper warnings.
+Updates land via `brew upgrade unipress`. On recent Homebrew (6.x), the first `install` or `upgrade` may refuse the tap until you trust it once — run `brew trust uniweb/unipress`, then re-run the command. The macOS binary is signed with the Proximify Inc. Developer ID and Apple-notarized — no Gatekeeper warnings.
 
 **Manual download (Windows, or any platform without Homebrew).** Grab the asset for your platform from [the releases page](https://github.com/uniweb/unipress/releases), make it executable (Unix), and put it somewhere on your `PATH`. On macOS and Linux, `/usr/local/bin/unipress` is a common location.
 

package/docs/troubleshooting.md

@@ -1,11 +1,24 @@
 # Troubleshooting
 
-When `unipress compile` fails, the error message names a class and a cause. This file pairs each with what it usually means and how to fix it.
+`unipress` surfaces actionable failures at install and compile time — each names a class and a cause. This file pairs each with what it usually means and how to fix it.
 
-Every `unipress` error exits with code `1` (user-addressable). Unknown errors exit with code `2` — those are internal bugs; re-run with `--verbose` and open an issue.
+Every `unipress` *compile* error exits with code `1` (user-addressable). Unknown errors exit with code `2` — those are internal bugs; re-run with `--verbose` and open an issue.
 
 ---
 
+## Homebrew: `Error: Refusing to load formula ... from untrusted tap uniweb/unipress`
+
+Recent Homebrew (6.x) won't load a formula from a third-party tap until you've trusted it once. This blocks both the first `brew install uniweb/unipress/unipress` and later `brew upgrade unipress`.
+
+Trust the tap once, then re-run the command:
+
+```bash
+brew trust uniweb/unipress
+brew upgrade unipress          # or: brew install uniweb/unipress/unipress
+```
+
+This is a Homebrew policy for third-party taps, not specific to unipress. The npm install (`npm i -g @uniweb/unipress`) and the prebuilt binaries on the [releases page](https://github.com/uniweb/unipress/releases) are unaffected.
+
 ## `ContentDirectoryError: content directory does not exist: <path>`
 
 The positional argument to `unipress compile` is wrong. Check your `cd` and the spelling. Paths are relative to the current working directory.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniweb/unipress",
-  "version": "0.4.20",
+  "version": "0.4.22",
   "description": "Compile a content directory into a document (PDF, EPUB, Paged.js HTML, Typst source bundle, DOCX, XLSX) using a Uniweb foundation. Five built-in templates: book, monograph, report, data-report, directory.",
   "type": "module",
   "publishConfig": {
@@ -49,14 +49,18 @@
     "prompts": "^2.4.2",
     "react": "^19.0.0",
     "react-dom": "^19.0.0",
-    "@uniweb/runtime": "0.8.18",
-    "@uniweb/core": "0.7.13",
-    "@uniweb/semantic-parser": "1.1.17",
     "@uniweb/content-reader": "1.1.12",
-    "@uniweb/build": "0.14.14"
+    "@uniweb/semantic-parser": "1.1.17",
+    "@uniweb/build": "0.14.15",
+    "@uniweb/core": "0.7.14",
+    "@uniweb/runtime": "0.8.19"
+  },
+  "devDependencies": {
+    "vitest": "^4.1.7"
   },
   "scripts": {
-    "test": "echo \"no tests yet\" && exit 0",
+    "test": "vitest run",
+    "test:watch": "vitest",
     "lint": "echo \"no lint yet\" && exit 0",
     "audit:docs": "node scripts/audit-documents.js"
   }

package/src/content-loader.js

@@ -41,13 +41,21 @@ function findCollectionRecords(fetchConfig, resolved) {
   return records
 }
 
-function attachSectionFetches(sections, resolved) {
+// Walk a section tree attaching collection records to each section's
+// parsedContent.data.<schema>. A section's OWN fetch is attached first
+// (so it wins under attachData's first-writer-wins guard); the page-level
+// `cascade` ({ schema, records }) then fills any remaining gap — for this
+// section AND every nested subsection. Threading the cascade through the
+// recursion is what lets a page-level `data:` declaration reach nested
+// children (declared via page.yml `nest:`), not just top-level sections.
+function attachSectionFetches(sections, resolved, cascade = null) {
   if (!Array.isArray(sections)) return
   for (const section of sections) {
     const records = findCollectionRecords(section.fetch, resolved)
     if (records) attachData(section, section.fetch.schema, records)
+    if (cascade) attachData(section, cascade.schema, cascade.records)
     if (Array.isArray(section.subsections) && section.subsections.length) {
-      attachSectionFetches(section.subsections, resolved)
+      attachSectionFetches(section.subsections, resolved, cascade)
     }
   }
 }
@@ -86,13 +94,14 @@ async function resolveLocalCollections(siteContent, sitePath) {
   )
 
   for (const page of siteContent.pages || []) {
+    // Page-level fetch cascades to every section on the page — top-level
+    // and nested alike. attachSectionFetches threads it through the whole
+    // section tree; a section's own fetch still takes priority.
     const pageRecords = findCollectionRecords(page.fetch, resolved)
-    if (pageRecords) {
-      for (const section of page.sections || []) {
-        attachData(section, page.fetch.schema, pageRecords)
-      }
-    }
-    attachSectionFetches(page.sections, resolved)
+    const cascade = pageRecords
+      ? { schema: page.fetch.schema, records: pageRecords }
+      : null
+    attachSectionFetches(page.sections, resolved, cascade)
   }
 
   // Stash the resolved arrays on the website config too, so any section