@jxsuite/feed 0.3.3 → 0.3.4

package/README.md

@@ -6,10 +6,10 @@
 
 `@jxsuite/feed` is the Jx extension that turns a content collection into something readers
 subscribe to. It contributes one class (`Feed`) and one project.json section, both reached through
-`jx-extension.json` — which names the class descriptor (`src/Feed.class.json`, whose `project` block
+`jx-extension.json`, which names the class descriptor (`src/Feed.class.json`, whose `project` block
 declares the section key) and the schema fragment that gives the section its shape:
 
-- **`feed`** — a map of feed name → feed object. Each entry names its `collection`, the `basePath`
+- **`feed`**: a map of feed name → feed object. Each entry names its `collection`, the `basePath`
   its entries are served under, and optional metadata (`title`, `description`, `author`), output
   shape (`formats`, `output`, `pageSize`, `archive`, `contentMode`), frontmatter field names
   (`dateField`, `updatedField`) and `language`. The schema
@@ -25,7 +25,7 @@ specs/extensions.md §1 exists to prevent. The capability contracts are specs/ex
 (`emit`) and §8.6 (`head`). User docs:
 [/docs/framework/site/feeds](https://jxsuite.com/docs/framework/site/feeds).
 
-**Atom 1.0 (RFC 4287) and JSON Feed 1.1. RSS 2.0 is deliberately not offered** — no standards body,
+**Atom 1.0 (RFC 4287) and JSON Feed 1.1. RSS 2.0 is deliberately not offered**: no standards body,
 unsettled `<guid>` semantics, and every reader handles Atom. All three standards this package binds
 (RFC 4287, JSON Feed 1.1, RFC 5005) are recorded as **Subset** in the Standards Alignment table of
 specs/site-architecture.md, each with an explicit list of what is not implemented. Read those rows
@@ -64,27 +64,27 @@ its collection key. A default build writes `dist/feed.xml` and `dist/feed.json`,
 `src/Feed.class.json` declares three capabilities, all implemented by the plain object exported as
 `Feed` from `src/feed.ts`:
 
-- **`projectData(sectionValue, ctx?)`** — timing `["compiler", "server"]`, the only one that also
+- **`projectData(sectionValue, ctx?)`**: timing `["compiler", "server"]`, the only one that also
   runs on the server. Normalizes the section (defaults applied) into `_project.feed`.
-- **`head(sectionValue, ctx)`** — timing `["compiler"]`. Returns one `<link rel="alternate">` per
-  configured format — one per format _and_ locale when the collection is localized — typed
+- **`head(sectionValue, ctx)`**: timing `["compiler"]`. Returns one `<link rel="alternate">` per
+  configured format (one per format _and_ locale when the collection is localized), typed
   `application/atom+xml` / `application/feed+json` and titled with the feed's `title` (or
   `"Feed"`). Both links survive `<head>` dedup because the merger keys a link on `rel` plus `href`
   plus whichever of `hreflang`, `type`, `media` or `sizes` is present
-  (specs/site-architecture.md §8.3) — for two formats that qualifier is `type`; for a localized
+  (specs/site-architecture.md §8.3). For two formats that qualifier is `type`; for a localized
   feed it is `hreflang`, and the links differ by `href` anyway.
-- **`emit(sectionValue, ctx)`** — timing `["compiler"]`. Returns `{ path, content }[]`; the host
+- **`emit(sectionValue, ctx)`**: timing `["compiler"]`. Returns `{ path, content }[]`; the host
   writes them.
 
 `head` exists separately from `emit` because the two answer different questions at different times
 (specs/extensions.md §8.6): `head` derives entries from **configuration** and runs once before the
 first page is built, while `emit` derives files from loaded content and runs after the last page has
-been written — too late to reach any `<head>`.
+been written, too late to reach any `<head>`.
 
 ## Emission model
 
-Everything happens inside the compiler's site build. `emit` runs at step 6e — after routes,
-components and the worker are generated, and before redirects and the `public/` copy; the **host**
+Everything happens inside the compiler's site build. `emit` runs at step 6e: after routes,
+components and the worker are generated, and before redirects and the `public/` copy. The **host**
 writes the returned records under `outDir` (paths are outDir-relative, a leading `/` is tolerated,
 and a path escaping `outDir` is a build error). The package never touches the filesystem, which is
 what makes both serializers testable against a literal array of items.
@@ -92,14 +92,14 @@ what makes both serializers testable against a literal array of items.
 Consequences worth knowing:
 
 - The `public/` copy runs after `emit`, so a same-named file in `public/` shadows an emitted feed.
-- The compiler writes `_headers` Content-Type rules — `application/atom+xml; charset=utf-8` for
-  `/feed.xml` and `/feed/archive/*`, `application/feed+json; charset=utf-8` for `/feed.json` — but
-  only for files the build produced, and the names it looks for are the **default** ones
-  (`packages/compiler/src/site/headers-emitter.ts`). A custom `output` gets no rule.
+- The compiler writes `_headers` Content-Type rules: `application/atom+xml; charset=utf-8` for
+  `/feed.xml` and `/feed/archive/*`, `application/feed+json; charset=utf-8` for `/feed.json`. It
+  writes them only for files the build produced, and the names it looks for are the **default**
+  ones (`packages/compiler/src/site/headers-emitter.ts`). A custom `output` gets no rule.
 
 Subpath exports (`@jxsuite/feed/atom`, `/json-feed`, `/shared`) resolve to TypeScript source, so the
-serializers and the pure feed model — `normalizeFeedConfig`, `entryToItem`, `sortItems`,
-`feedUpdated`, `paginate`, `feedPath` — are importable on their own.
+serializers and the pure feed model are importable on their own: `normalizeFeedConfig`,
+`entryToItem`, `sortItems`, `feedUpdated`, `paginate`, `feedPath`.
 
 ## Surprises
 
@@ -107,7 +107,7 @@ serializers and the pure feed model — `normalizeFeedConfig`, `entryToItem`, `s
   older entries are then published nowhere. `archive: true` is what preserves them.
 - **Archives are chunked from the oldest end.** Chunking from the newest would reshuffle every
   boundary on each new entry; counting from the oldest means archive 1 keeps its contents forever
-  and only the newest archive changes — RFC 5005 §2 asks that a published archive not change.
+  and only the newest archive changes. RFC 5005 §2 asks that a published archive not change.
 - **`<fh:complete/>` needs no archives _and_ nothing trimmed.** A document trimmed by `pageSize`
   with archives off is not complete, and says so by omission.
 - **RFC 5005 archives are Atom-only.** The JSON Feed branch writes exactly one document and never
@@ -117,8 +117,8 @@ serializers and the pure feed model — `normalizeFeedConfig`, `entryToItem`, `s
   guess. Give the collection schema `"format": "date"` so the parser's date coercion
   (`coerceEntryDates`, specs/parser.md §9.3) normalizes the field first. An entry with no readable
   date falls back to `_meta.mtime`.
-- **The feed-level `<updated>` is the newest item, never the build time** — a feed stamped with the
-  build re-notifies every subscriber on every deploy. An empty feed renders
+- **The feed-level `<updated>` is the newest item, never the build time**, because a feed stamped
+  with the build re-notifies every subscriber on every deploy. An empty feed renders
   `<updated>1970-01-01T00:00:00Z</updated>`.
 - **A localized collection is several feeds, not one, and this is not configurable.** When the named
   collection's `source` contains `{locale}`, each language is published in its own URL prefix
@@ -128,17 +128,17 @@ serializers and the pure feed model — `normalizeFeedConfig`, `entryToItem`, `s
   know which locale its page is in.
 - **`contentMode` branches only on `"full"`** (`src/shared.ts`), which is what adds
   `<content type="html">` / `content_html`; the summary is emitted either way. A third value,
-  `"none"`, was accepted until 0.3.0 and did nothing — JSON Feed 1.1 requires one of
+  `"none"`, was accepted until 0.3.0 and did nothing. JSON Feed 1.1 requires one of
   `content_html`/`content_text`, so "omit the content" was never expressible.
 - **A feed naming a collection that is not loaded is skipped with a console warning**, not a build
   error.
-- **The schema requires `collection` and `basePath`, but the runtime tolerates their absence** —
+- **The schema requires `collection` and `basePath`, but the runtime tolerates their absence**:
   `collection` falls back to the section key and `basePath` to `"/"`. Validation, not
   `normalizeFeedConfig`, is what enforces them.
 
 ## Versioning
 
-Published to npm as `@jxsuite/feed` — TypeScript source, like every `@jxsuite` package, following
+Published to npm as `@jxsuite/feed`, TypeScript source like every `@jxsuite` package, following
 the monorepo's release train. Its only runtime dependency is `@jxsuite/schema`; extensions may
-depend on core packages but never the reverse — no core package lists this one as a runtime
+depend on core packages but never the reverse: no core package lists this one as a runtime
 dependency or imports it from `src/`, and `scripts/check-dep-rules.ts` enforces that.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jxsuite/feed",
-  "version": "0.3.3",
+  "version": "0.3.4",
   "description": "Syndication feeds for Jx: Atom (RFC 4287) and JSON Feed emitted from content collections at build time",
   "license": "MIT",
   "repository": {
@@ -32,10 +32,10 @@
     "build": "bun run prepare",
     "test": "bun test --isolate",
     "test:coverage": "bun test --isolate --coverage",
-    "upgrade": "bunx npm-check-updates -u && bun install"
+    "upgrade": "bun update --latest && bun install"
   },
   "dependencies": {
-    "@jxsuite/schema": "^1.9.0"
+    "@jxsuite/schema": "^2.0.0"
   },
   "devDependencies": {
     "ajv": "^8.20.0"