uniweb 0.10.2 → 0.10.5

package/README.md

@@ -257,7 +257,7 @@ You can delete the `foundation/` folder entirely and point your site at a publis
 
 _Site-first_ — You're building a website. The foundation is your component library, co-developed with the site. This is the common case.
 
-_Foundation-first_ — You're building a component system. The site is a test harness with sample content. The real sites live elsewhere—other repositories, other teams, or managed on [uniweb.app](https://uniweb.app). Use `uniweb add site` to add multiple test sites exercising a shared foundation.
+_Foundation-first_ — You're building a component system. The site is a test harness with sample content. The real sites live elsewhere—other repositories, other teams, or managed on [hub.uniweb.app](https://hub.uniweb.app). Use `uniweb add site` to add multiple test sites exercising a shared foundation.
 
 ## Growing Your Project
 
@@ -299,11 +299,11 @@ The structure you start with scales without rewrites:
 
 1. **Single project** — One site, one foundation. Develop and deploy together. Most projects stay here.
 
-2. **Published foundation** — Release your foundation as an npm package or to [uniweb.app](https://uniweb.app). Other sites can use it without copying code.
+2. **Published foundation** — Release your foundation as an npm package or to [hub.uniweb.app](https://hub.uniweb.app). Other sites can use it without copying code.
 
 3. **Multiple sites** — Several sites share one foundation. Update components once, every site benefits.
 
-4. **Platform-managed sites** — Sites built on [uniweb.app](https://uniweb.app) with visual editing tools can use your foundation. You develop components locally; content teams work in the browser.
+4. **Platform-managed sites** — Sites built on [hub.uniweb.app](https://hub.uniweb.app) with visual editing tools can use your foundation. You develop components locally; content teams work in the browser.
 
 Start with local files deployed anywhere. The same foundation works across all these scenarios.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "uniweb",
-  "version": "0.10.2",
+  "version": "0.10.5",
   "description": "Create structured Vite + React sites with content/code separation",
   "type": "module",
   "bin": {
@@ -41,14 +41,14 @@
     "js-yaml": "^4.1.0",
     "prompts": "^2.4.2",
     "tar": "^7.0.0",
-    "@uniweb/core": "0.7.1",
-    "@uniweb/runtime": "0.8.2",
-    "@uniweb/kit": "0.9.1"
+    "@uniweb/core": "0.7.3",
+    "@uniweb/kit": "0.9.3",
+    "@uniweb/runtime": "0.8.4"
   },
   "peerDependencies": {
-    "@uniweb/build": "0.10.2",
-    "@uniweb/content-reader": "1.1.4",
-    "@uniweb/semantic-parser": "1.1.9"
+    "@uniweb/build": "0.11.2",
+    "@uniweb/semantic-parser": "1.1.11",
+    "@uniweb/content-reader": "1.1.5"
   },
   "peerDependenciesMeta": {
     "@uniweb/build": {

package/partials/agents.md

@@ -417,6 +417,31 @@ Access: `content.snippets[0]` → `{ language: 'jsx', code: 'function Hello() {.
 
 Both appear in `content.sequence` for document-order rendering. The difference: tagged data blocks are parsed and extracted to `content.data`; code snippets are preserved and collected in `content.snippets`. `<Prose>` handles this automatically — it renders code snippets with syntax highlighting and skips tagged data blocks, which components access separately via `content.data`.
 
+### Math (LaTeX)
+
+Authors write LaTeX directly in markdown; the browser renders real math natively. The LaTeX is compiled to MathML Core **at build time** — no runtime math library ships to the browser, no CSS from a math package is required.
+
+Three forms, matching Pandoc / GitHub / VS Code / Jupyter / Obsidian convention:
+
+| Form | Mode | Example |
+|---|---|---|
+| `$x^2$` | Inline | `Let $f(x) = ax + b$ be a function.` |
+| `$$x^2$$` | Display (block when on its own line, inline display mid-paragraph) | `$$\sum_{i=1}^n i$$` |
+| ` ```math ` fence | Display (multi-line friendly) | see below |
+| `\$` | Literal `$` | `The price is \$20.` |
+
+Multi-line display math uses a `math` code fence:
+
+````markdown
+```math
+\int_0^\infty e^{-x^2}\,dx = \frac{\sqrt{\pi}}{2}
+```
+````
+
+Disambiguation for `$...$`: a dollar-delimited span counts as math only when the body has no whitespace next to the delimiters *and* the closing `$` is not immediately followed by a digit. So `It costs $5 and $10 total` and `Budget: $200` stay as prose without any escaping, while `Let $f(x) = 5$ be a function` is math. Use `\$` when you need a literal `$` in content where the rules would otherwise trip it up.
+
+Math rides through the same content pipeline as everything else — it appears in prerendered HTML, survives `compile('epub')` and `compile('pagedjs')`, and roundtrips cleanly through the editor. Component code needs nothing special; `<Prose>` and `<Text>` already render the MathML that the pipeline embedded.
+
 ### Composition: Nesting and Embedding
 
 Pages are sequences of sections — that's the obvious composition layer. But the framework supports real nesting: sections containing other sections, and sections containing embedded components. And it does this without leaving markdown.
@@ -891,7 +916,7 @@ fetch:
   limit: 3
 ```
 
-**Lean lists with `deferred:`.** Collections with heavy fields (article bodies, large nested arrays) can declare `deferred: [body]` in `site.yml`. The cascade payload omits those fields; per-record full files are emitted at `/data/<name>/<slug>.json` (markdown-backed collections) or fetched from an author-declared `detailUrl:` pattern (API-backed collections). On dynamic-route pages the focused entity's full record is delivered automatically; elsewhere components fetch on demand via the `useEntityDetail` kit hook.
+**Lean lists with `deferred:`.** Collections with heavy fields (article bodies, large nested arrays) can declare `deferred: [body]` in `site.yml`. The cascade payload omits those fields; per-record full files are emitted at `/data/<name>/<slug>.json` (file-based collections — markdown, YAML, or JSON) or fetched from an author-declared `detailUrl:` pattern (API-backed collections). On dynamic-route pages the focused entity's full record is delivered automatically; elsewhere components fetch on demand via the `useEntityDetail` kit hook.
 
 **Component-side fetching.** When a component genuinely needs to fetch something on its own (a search box, a "load more" button, a popover that lazy-loads), use the kit hooks (`useFetched`, `useCacheEntry`, `useEntityDetail`). They share the framework's cache and dispatcher with declarative fetches; same-key requests dedupe automatically.
 

package/src/commands/build.js

@@ -11,9 +11,10 @@
  */
 
 import { existsSync, readFileSync } from 'node:fs'
-import { resolve, join } from 'node:path'
+import { resolve, join, dirname } from 'node:path'
 import { spawn } from 'node:child_process'
 import { writeFile, mkdir } from 'node:fs/promises'
+import { createRequire } from 'node:module'
 
 // Import build utilities from @uniweb/build
 import {
@@ -123,6 +124,46 @@ function runCommand(command, args, cwd) {
   })
 }
 
+/**
+ * Resolve the project's local Vite binary.
+ *
+ * We intentionally do NOT fall back to `npx vite`: npx resolves through npm's
+ * global cache, which may hold a stale Vite version (e.g. Vite 5 ignores
+ * lib.fileName for CSS and always emits style.css). Using the project's local
+ * Vite guarantees the version declared in package.json is the one that runs.
+ *
+ * @param {string} projectDir
+ * @returns {string} Absolute path to the vite CLI entry
+ */
+function resolveLocalVite(projectDir) {
+  const require = createRequire(join(projectDir, 'package.json'))
+  let pkgJsonPath
+  try {
+    pkgJsonPath = require.resolve('vite/package.json')
+  } catch {
+    throw new Error(
+      `Vite is not installed in ${projectDir}.\n` +
+      `Run \`pnpm install\` (or npm/yarn install) in the project before building.`
+    )
+  }
+  const pkg = JSON.parse(readFileSync(pkgJsonPath, 'utf8'))
+  const binRel = typeof pkg.bin === 'string' ? pkg.bin : pkg.bin?.vite
+  if (!binRel) {
+    throw new Error(`Could not find vite bin entry in ${pkgJsonPath}`)
+  }
+  return join(dirname(pkgJsonPath), binRel)
+}
+
+/**
+ * Run the project's local Vite with the given args.
+ * @param {string} projectDir
+ * @param {string[]} args - e.g. ['build']
+ */
+async function runLocalVite(projectDir, args) {
+  const viteBin = resolveLocalVite(projectDir)
+  await runCommand(process.execPath, [viteBin, ...args], projectDir)
+}
+
 /**
  * Build a foundation
  */
@@ -158,7 +199,7 @@ async function buildFoundation(projectDir, options = {}) {
 
   // Check if vite.config.js uses the generated entry
   // For now, just run the standard vite build
-  await runCommand('npx', ['vite', 'build'], projectDir)
+  await runLocalVite(projectDir, ['build'])
 
   // Vite's foundation plugin generates dist/meta/schema.json
   // and processes preview images during the build.
@@ -351,7 +392,7 @@ async function buildSite(projectDir, options = {}) {
   info('Building site...')
 
   // Run vite build for sites
-  await runCommand('npx', ['vite', 'build'], projectDir)
+  await runLocalVite(projectDir, ['build'])
 
   success('Site build complete')