@uniweb/core 0.15.0 → 0.16.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uniweb/core",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Core classes for the Uniweb platform - Uniweb, Website, Page, Block",
   "type": "module",
   "exports": {
@@ -42,8 +42,8 @@
     "vitest": "^4.1.7"
   },
   "dependencies": {
-    "@uniweb/semantic-parser": "^1.4.0",
-    "@uniweb/theming": "^0.1.15"
+    "@uniweb/theming": "^0.1.15",
+    "@uniweb/semantic-parser": "^1.4.0"
   },
   "scripts": {
     "test": "vitest run"

package/src/index.js

@@ -49,11 +49,6 @@ export {
 } from './data-paths.js'
 export { evaluate as evaluateWhere, match as matchWhere } from './where.js'
 export { isRichSchema } from './schemas.js'
-// ⛔ `normalizeSchema` MOVED to `@uniweb/schemas/editor-form` (2026-09-01) —
-// it is editor-only and never called `isRichSchema`. Still exported here for
-// ONE more release so `frontend` (a `workspace:*` pin, so a removal is live
-// at commit time) can migrate its single import. Delete both lines then.
-export { normalizeSchema } from './schemas.js'
 // ⛔ `Tracker` is NOT on the package entry. It is a FEATURE, not part of the
 // object graph this package exists to define, and putting it here made every
 // consumer of core carry 1,576 gzip of it -- press, unipress, `@uniweb/api`

package/src/schemas.js

@@ -1,18 +1,26 @@
 /**
- * Shared helpers for rich form schemas.
- *
- * Rich schemas live under `data.schemas` in a component's meta.js. They
- * drive two author input paths that both land at `content.data[schema-id]`:
- *
- *   1. Tagged markdown blocks (``` ```yaml:<id> ``` ```)
- *   2. The FormBlock editor widget
- *
- * Detection is shared across the build pipeline (emit path), the runtime
- * (dispatch in applySchemas), and the editor (filter for FormBlock menu)
- * so all three agree on what counts as a rich schema.
- *
- * Conditional field visibility (a rich-schema feature) is an editor-only
- * concern and is not implemented here — the editor owns its own evaluator.
+ * The rich-form-schema predicate. One function, and deliberately only one.
+ *
+ * Rich schemas live under `data.schemas` in a component's meta.js. They drive
+ * two author input paths that both land at `content.data[schema-id]`: tagged
+ * markdown blocks (``` ```yaml:<id> ``` ```) and the editor's FormBlock widget.
+ *
+ * `isRichSchema` is a **dispatch** predicate — "is this already the rich shape?"
+ * — and it is read at render by `runtime/src/prepare-props.js` (`applySchemas`)
+ * and at build by `build/src/runtime-schema.js`. Both are on the hot path of
+ * every site, which is what earns it a place in this package.
+ *
+ * ⛔ **Do not add editor-side schema code here.** `normalizeSchema` — "can this
+ * be edited, and as what?" — sat beside this function until 2026-09-01 purely
+ * because the two were adjacent; it never called `isRichSchema` and had no
+ * consumer outside the editor. `@uniweb/core` loads on every site in every lane
+ * and is not tree-shaken on the hosted one, so an editor-only function on its
+ * entry is paid for by every visitor of every site. It now lives in the
+ * zero-dependency leaf that owns what a data-schema *means*:
+ * **`@uniweb/schemas/editor-form`**.
+ *
+ * Conditional field visibility (a rich-schema feature) is likewise editor-only
+ * and is not implemented here — the editor owns its own evaluator.
  */
 
 /**
@@ -35,91 +43,3 @@ export function isRichSchema(schema) {
   if (schema.childSchema && typeof schema.childSchema === 'object') return true
   return false
 }
-
-/**
- * ⛔ **DEPRECATED — MOVED to `@uniweb/schemas/editor-form` (2026-09-01).**
- * This copy stays only so `frontend`, which pins core as `workspace:*` and
- * would break at commit time, can migrate its one import. Delete it once that
- * lands; nothing else in any repo reads it.
- *
- * ⭐ **It never belonged here.** It does not call `isRichSchema` and never did
- * — it re-inlines the same three checks — so nothing but adjacency held it in
- * this file. The two answer different questions for different audiences:
- * `isRichSchema` is a render-time dispatch predicate (`prepare-props.js`,
- * `runtime-schema.js`) and stays; this is read only by an editor, while core
- * ships to every site in every lane and is not tree-shaken on the hosted one.
- *
- * Normalize any authored `data:` schema shape to the rich form the editor
- * renders, or null when it is not a single form at all.
- *
- * WHY THIS EXISTS. `isRichSchema` answers "is this already the rich shape?",
- * which is the right question for dispatch and the wrong one for "can this be
- * edited". There are THREE authored shapes and it accepts exactly one:
- *
- *   { fields: [ {id, …} ] }        meta.js inline rich-form      → true
- *   { fields: { name: spec } }     a RESOLVED NAMED REF          → FALSE
- *   { name: spec }                 meta.js inline field map      → false
- *
- * The middle row is the important one and the reason this helper exists at all
- * (it once read "the reason it is in `core` rather than in the editor" — that
- * was the wrong conclusion from a right observation: the gap is real, closing
- * it in one shared place is right, and `@uniweb/schemas` is that place).
- * A named ref (`'@/article'`, `'@std/person'`) is the
- * FIRST authoring form the docs show, and `validateAndNormalizeSchema` in the
- * build resolves it to `{ fields: <MAP> }` — a map, not an array. So filtering
- * with `isRichSchema` discards not merely "simple" schemas but the primary
- * documented one, and any consumer that wants to render it has to re-derive the
- * conversion. Three consumers re-deriving it is exactly the divergence the
- * shared predicate was introduced to prevent.
- *
- * A field map is an unordered `fields[]`, so the conversion is mechanical.
- * Ordering comes from `Object.entries`, which is insertion order for string keys
- * — i.e. the order the author wrote, which is the order a form should show.
- *
- * `sections` returns null on purpose: a sectioned data-schema describes a Model
- * with several sections, which is not one form. Flattening it would invent a
- * layout the author never expressed.
- *
- * @param {*} schema - any authored or resolved `data:` schema value
- * @returns {{ fields: Array<object> } | null} the rich shape, or null
- */
-export function normalizeSchema(schema) {
-  if (!schema || typeof schema !== 'object' || Array.isArray(schema))
-    return null
-
-  // Already rich — hand back untouched. Composite/childSchema variants are rich
-  // by `isRichSchema`'s definition and are not ours to reshape.
-  if (Array.isArray(schema.fields)) return schema
-  if (schema.isComposite === true || schema.childSchema) return schema
-
-  // A sectioned Model is not a single form.
-  if (schema.sections !== undefined) return null
-
-  const mapToFields = (map) =>
-    Object.entries(map).map(([id, spec]) =>
-      typeof spec === 'string' ? { id, type: spec } : { id, ...spec }
-    )
-
-  // A resolved named ref: `fields` present, as a map.
-  if (schema.fields && typeof schema.fields === 'object') {
-    const { fields, ...rest } = schema
-    return { ...rest, fields: mapToFields(fields) }
-  }
-
-  // An inline field map: no `fields` key, so every value must be an OBJECT
-  // carrying `type`.
-  //
-  // The bare-type string shorthand (`{ cpu: 'string' }`) is deliberately NOT
-  // accepted here, even though schema FILES support it. Without a `fields` key
-  // there is nothing to distinguish it from ordinary data: `{ name: 'Acme' }` and
-  // `{ cpu: 'string' }` are the same shape, and an earlier cut of this function
-  // turned `{ name, description }` into a two-field form. Erring toward null
-  // costs an author the object spelling; erring the other way invents a form out
-  // of a config block.
-  const entries = Object.entries(schema)
-  if (!entries.length) return null
-  const isFieldSpec = ([, v]) =>
-    v && typeof v === 'object' && !Array.isArray(v) && v.type !== undefined
-  if (!entries.every(isFieldSpec)) return null
-  return { fields: mapToFields(schema) }
-}