canopycms 0.0.67-int.90 → 0.0.67

package/dist/utils/typed-filename.js

@@ -1,82 +1,46 @@
 import { isValidId } from '../id.js';
-// Lives here rather than in content-listing.ts, where it was born, purely so dependency-light
-// modules can use it: content-listing imports ContentStore, so anything content-store itself
-// imports (url-collision.ts) cannot reach back into it without a cycle. content-listing
-// re-exports this and `canopycms/server` re-exports it from there, so the public surface is
-// unchanged.
+// Lives here rather than in content-listing.ts so dependency-light modules can use it:
+// content-listing imports ContentStore, so url-collision.ts (which content-store imports) cannot
+// reach back into it without a cycle. content-listing and `canopycms/server` re-export it.
 /**
  * Parse a Canopy content filename into its `{type}.{slug}.{id}.{ext}` parts.
  *
- * ## Filename grammar
+ * The slug may itself contain dots (`getting.started.guide`), so type and ID anchor the split:
+ * the ID is the second-to-last dot-separated segment, the slug is everything between the type and
+ * it (lowercased), and the extension is stripped. The ID is a 12-character Base58 content ID, and
+ * a would-be ID segment that fails `isValidId` rejects the whole parse.
  *
- * Every entry file on disk is named `{type}.{slug}.{id}.{ext}`:
- * - `type` — the entry type name (a key in the collection's `entries` config).
- * - `slug` — the entry's URL slug. May itself contain dots (e.g. a slug of
- *   `getting.started.guide`), so the type and ID anchor the split: the ID is
- *   always the second-to-last dot-separated segment, and the slug is
- *   everything between the type and the ID. The returned `slug` is
- *   lowercased.
- * - `id` — a 12-character Base58 content ID (`generateId()`/`isValidId()`).
- *   Base58 excludes the ambiguous characters `0`, `O`, `I`, `l` so IDs are
- *   unambiguous when read aloud or hand-transcribed. A filename whose
- *   would-be ID segment doesn't pass `isValidId` is rejected — the whole
- *   parse returns `null`, even if the rest of the shape looks right.
- * - `ext` — the format extension (`.md`, `.mdx`, `.json`, `.yaml`), stripped
- *   before parsing and not part of the returned result.
+ * `filename` must be a bare filename, and **that precondition is not enforced**: the parser splits
+ * purely on `.`, so a `/` or `\` is neither rejected nor treated as special and becomes part of
+ * whichever segment it falls in (`'foo/bar.slug.<validId>.md'` gives `type: 'foo/bar'`). Strip the
+ * directory component yourself (`path.basename`) — every internal caller does. A leading-dot
+ * filename is always rejected, matching `extractEntryTypeFromFilename` in `content-id-index.ts`.
  *
- * @param filename - The bare filename (no directory component). **This precondition is
- *   not enforced.** The parser splits purely on `.`, so a `/` or `\` you pass in is not
- *   rejected and is not treated as special — it becomes part of whichever segment it
- *   falls in, most often the `type` segment (e.g. `'foo/bar.slug.<validId>.md'` parses
- *   to `type: 'foo/bar'`). Strip any directory component yourself (e.g.
- *   `path.basename(filePath)`) before calling this — every internal caller already does.
- * @param entryTypes - When provided, the parsed `type` segment must match one
- *   of these entry types by name, or the parse is rejected (this is how
- *   `listCollectionEntries` filters out files that don't belong to the
- *   collection's configured entry types). Omit this argument to parse
- *   structurally without validating the type against a known list — useful
- *   for adopter code that needs to recover `{type, slug, id}` from a
- *   filename without having a schema/entry-types list on hand (e.g. a
- *   filesystem walk over content for tooling or diagnostics). Even without
- *   `entryTypes`, a leading-dot filename (dotfile, editor swap/backup file)
- *   is always rejected — an empty string is never a legal type, matching the
- *   `filename.startsWith('.')` guard `extractEntryTypeFromFilename` in
- *   `content-id-index.ts` already applies.
- * @returns `{ type, slug, id }`, or `null` if `filename` doesn't match the
- *   `{type}.{slug}.{id}.{ext}` shape (too few segments, no extension, a
- *   leading dot, an invalid ID, or — when `entryTypes` is given — an
- *   unrecognized type). `id` is validated (`isValidId`) and safe to trust. **`slug` is
- *   not** — it is the raw dot-joined middle segment(s), lowercased, cast to the branded
- *   `Slug` type without running `parseSlug`'s validation. A filename with an
- *   unconventional slug segment (e.g. containing a space, or a dot) still parses and still
- *   receives the `Slug` brand. Callers that need a validated slug must run the result
- *   through `parseSlug` themselves; this function's contract is "split the filename
- *   grammar apart," not "validate every part." `listCollectionEntries` (content-listing.ts)
- *   is exactly such a caller that does NOT re-validate — it lists the file and computes a
- *   `urlPath` for it regardless — so a dotted slug listed this way builds and gets
- *   advertised (sitemap, `generateStaticParams`) but can never be read back through
- *   `readByUrlPath`, which does run every URL-resolution candidate through `parseSlug`.
- *   `static/index.ts`'s `assertRoutableSlugs` is the build-time guard that catches this.
+ * `entryTypes`, when given, restricts the `type` segment to those entry types — how
+ * `listCollectionEntries` filters out files that do not belong to the collection. Omit it to
+ * parse structurally, for adopter code recovering `{type, slug, id}` with no schema on hand.
+ *
+ * `id` is validated and safe to trust. **`slug` is not** — it is the raw dot-joined middle,
+ * lowercased and cast to the branded `Slug` without `parseSlug`'s validation, so a slug holding a
+ * space or a dot still parses and still carries the brand. Callers needing a validated slug run
+ * `parseSlug` themselves. `listCollectionEntries` does NOT, so a dotted slug is listed and
+ * advertised (sitemap, `generateStaticParams`) yet can never be read back through `readByUrlPath`,
+ * which runs every candidate through `parseSlug`; `static/index.ts`'s `assertRoutableSlugs` is the
+ * build-time guard for that.
  */
 export const parseTypedFilename = (filename, entryTypes) => {
-    // Reject dotfiles outright (matching extractEntryTypeFromFilename's guard in
-    // content-id-index.ts): a leading dot can never be a legal entry type, and this
-    // is exactly the shape of the files a structural (no-entryTypes) parse would
-    // otherwise misparse -- e.g. '.hidden.file.aB3cD4eF5gH6.md' -> potentialType ''.
+    // A leading dot can never be a legal entry type, and a dotfile is exactly what a structural
+    // (no-entryTypes) parse would otherwise misparse: '.hidden.file.aB3cD4eF5gH6.md' -> type ''.
     if (filename.startsWith('.'))
         return null;
-    // Remove extension
     const lastDot = filename.lastIndexOf('.');
     if (lastDot === -1)
         return null;
     const nameWithoutExt = filename.slice(0, lastDot);
-    // Parse: {type}.{slug}.{id}
     const parts = nameWithoutExt.split('.');
     if (parts.length < 3)
         return null;
     const potentialType = parts[0];
-    // When a known-types list is supplied, the first segment must match one of
-    // them. Without it, any non-empty first segment is accepted as the type.
     if (entryTypes && !entryTypes.some((e) => e.name === potentialType)) {
         return null;
     }

package/dist/utils/url-prefix.d.ts

@@ -21,9 +21,9 @@
  * Whether `url` is a DECLARED off-site pointer - a scheme-qualified absolute URL
  * (`https://example.com/x`) or a literal protocol-relative one (`//cdn.example.com/x`).
  *
- * Deliberately narrower than "resolves off-origin": a WHATWG-backslash-equivalent spelling
- * (`/\evil.com`, `\\evil.com`, `\/evil.com` — see `utils/sanitize-href.ts`'s
- * `isImplicitlyOffOrigin`) also resolves off-origin in a browser, but is NOT recognized here as
+ * Deliberately narrower than "resolves off-origin": a backslash-equivalent spelling (see
+ * `utils/sanitize-href.ts`'s `declaresScheme` and `isImplicitlyOffOrigin`)
+ * also resolves off-origin in a browser, but is NOT recognized here as
  * an intentional off-site pointer the way a literal `//cdn…` is. Callers handle that case
  * separately, by neutralizing (`neutralizeImplicitOffOrigin`) rather than passing through: a
  * `false` result here isn't a guarantee the value is a safe site-relative path on its own, only

package/dist/utils/url-prefix.js

@@ -22,9 +22,9 @@ import { declaresScheme, neutralizeImplicitOffOrigin } from './sanitize-href.js'
  * Whether `url` is a DECLARED off-site pointer - a scheme-qualified absolute URL
  * (`https://example.com/x`) or a literal protocol-relative one (`//cdn.example.com/x`).
  *
- * Deliberately narrower than "resolves off-origin": a WHATWG-backslash-equivalent spelling
- * (`/\evil.com`, `\\evil.com`, `\/evil.com` — see `utils/sanitize-href.ts`'s
- * `isImplicitlyOffOrigin`) also resolves off-origin in a browser, but is NOT recognized here as
+ * Deliberately narrower than "resolves off-origin": a backslash-equivalent spelling (see
+ * `utils/sanitize-href.ts`'s `declaresScheme` and `isImplicitlyOffOrigin`)
+ * also resolves off-origin in a browser, but is NOT recognized here as
  * an intentional off-site pointer the way a literal `//cdn…` is. Callers handle that case
  * separately, by neutralizing (`neutralizeImplicitOffOrigin`) rather than passing through: a
  * `false` result here isn't a guarantee the value is a safe site-relative path on its own, only

package/dist/validation/block-structural-keys.d.ts

@@ -1,41 +1,26 @@
 /**
- * The keys a block item carries that are STRUCTURE rather than content.
+ * The keys a block item carries that are STRUCTURE rather than content: the
+ * discriminator naming the block's TEMPLATE — a category label shared by every
+ * block of that kind, not an identifier for this one — present in either on-disk
+ * shape: canonical `{ template: 'hero', value: {...} }` or the defensive inline
+ * `{ _type: 'hero', ...fields }` (see `resolveBlockItem` in `./field-traversal`).
  *
- * A block on disk is `{ template: 'hero', value: { ...fields } }` — the canonical shape the
- * editor writes and `ContentStore` persists — or, defensively, the inline `{ _type: 'hero',
- * ...fields }` shape (see `resolveBlockItem` in `./field-traversal`). Either way the
- * discriminator names the block's TEMPLATE, which is a category label shared by every block of
- * that kind, not an identifier for this particular block.
+ * The list lives here, not in either caller, so the two below can't drift apart:
+ * - `findUnknownKeys` (./entry-validator) must not report the discriminator as a
+ *   stale key — it isn't a schema field, but is supposed to be there.
+ * - `looksLikeSameItem` (../utils/content-serialize) must not accept it as evidence
+ *   two list items are the same item — every `hero` shares `template: hero`, so
+ *   counting it would migrate an editorial comment off a deleted block onto an
+ *   unrelated survivor.
  *
- * That distinction matters to two callers for opposite-looking reasons, which is why the list
- * lives here rather than in either of them:
- *
- * - `findUnknownKeys` (./entry-validator) must not report the discriminator as a stale key: it
- *   is not a schema field, but it is supposed to be there.
- * - `looksLikeSameItem` (../utils/content-serialize) must not accept the discriminator as
- *   evidence that two list items are the same item: two `hero` blocks share `template: hero`,
- *   so counting it migrated an editorial comment off a deleted block onto an unrelated
- *   survivor.
- *
- * A single list keeps those two from drifting apart — a third discriminator added for one of
- * them but not the other would resurrect exactly one of those bugs.
- *
- * Note that two other readers deliberately still spell the keys out themselves, because they
- * READ the discriminator's value positionally rather than testing membership, and they do not
- * agree on precedence: `resolveBlockItem` prefers `template`, while `ai/json-to-markdown.ts`
- * prefers `_type`. Reconciling that is a behaviour question, not a refactor — see
+ * Two other readers still spell the keys out themselves — they read the value
+ * positionally and disagree on precedence (`resolveBlockItem` prefers `template`,
+ * `ai/json-to-markdown.ts` prefers `_type`) — see
  * `.claude/future-tasks/block-discriminator-precedence-disagreement.md`.
  *
- * Dependency-free on purpose: both importers are reachable from contexts that must not pull in
+ * Dependency-free on purpose: both importers reach contexts that must not pull in
  * schema types or node built-ins.
  */
-/**
- * The discriminator keys, in the precedence `resolveBlockItem` reads them.
- *
- * Ordered (rather than a bare Set) so a caller that needs the VALUE can iterate it, and so the
- * canonical shape's key stays visibly first.
- */
-export declare const BLOCK_DISCRIMINATOR_KEYS: readonly ["template", "_type"];
 /** Membership form of {@link BLOCK_DISCRIMINATOR_KEYS}, for the two set-test callers. */
 export declare const BLOCK_STRUCTURAL_KEYS: ReadonlySet<string>;
 /** True for a key that names a block's template rather than holding any of its content. */

package/dist/validation/block-structural-keys.js

@@ -1,41 +1,31 @@
 /**
- * The keys a block item carries that are STRUCTURE rather than content.
+ * The keys a block item carries that are STRUCTURE rather than content: the
+ * discriminator naming the block's TEMPLATE — a category label shared by every
+ * block of that kind, not an identifier for this one — present in either on-disk
+ * shape: canonical `{ template: 'hero', value: {...} }` or the defensive inline
+ * `{ _type: 'hero', ...fields }` (see `resolveBlockItem` in `./field-traversal`).
  *
- * A block on disk is `{ template: 'hero', value: { ...fields } }` — the canonical shape the
- * editor writes and `ContentStore` persists — or, defensively, the inline `{ _type: 'hero',
- * ...fields }` shape (see `resolveBlockItem` in `./field-traversal`). Either way the
- * discriminator names the block's TEMPLATE, which is a category label shared by every block of
- * that kind, not an identifier for this particular block.
+ * The list lives here, not in either caller, so the two below can't drift apart:
+ * - `findUnknownKeys` (./entry-validator) must not report the discriminator as a
+ *   stale key — it isn't a schema field, but is supposed to be there.
+ * - `looksLikeSameItem` (../utils/content-serialize) must not accept it as evidence
+ *   two list items are the same item — every `hero` shares `template: hero`, so
+ *   counting it would migrate an editorial comment off a deleted block onto an
+ *   unrelated survivor.
  *
- * That distinction matters to two callers for opposite-looking reasons, which is why the list
- * lives here rather than in either of them:
- *
- * - `findUnknownKeys` (./entry-validator) must not report the discriminator as a stale key: it
- *   is not a schema field, but it is supposed to be there.
- * - `looksLikeSameItem` (../utils/content-serialize) must not accept the discriminator as
- *   evidence that two list items are the same item: two `hero` blocks share `template: hero`,
- *   so counting it migrated an editorial comment off a deleted block onto an unrelated
- *   survivor.
- *
- * A single list keeps those two from drifting apart — a third discriminator added for one of
- * them but not the other would resurrect exactly one of those bugs.
- *
- * Note that two other readers deliberately still spell the keys out themselves, because they
- * READ the discriminator's value positionally rather than testing membership, and they do not
- * agree on precedence: `resolveBlockItem` prefers `template`, while `ai/json-to-markdown.ts`
- * prefers `_type`. Reconciling that is a behaviour question, not a refactor — see
+ * Two other readers still spell the keys out themselves — they read the value
+ * positionally and disagree on precedence (`resolveBlockItem` prefers `template`,
+ * `ai/json-to-markdown.ts` prefers `_type`) — see
  * `.claude/future-tasks/block-discriminator-precedence-disagreement.md`.
  *
- * Dependency-free on purpose: both importers are reachable from contexts that must not pull in
+ * Dependency-free on purpose: both importers reach contexts that must not pull in
  * schema types or node built-ins.
  */
 /**
- * The discriminator keys, in the precedence `resolveBlockItem` reads them.
- *
- * Ordered (rather than a bare Set) so a caller that needs the VALUE can iterate it, and so the
- * canonical shape's key stays visibly first.
+ * The discriminator keys, in the precedence `resolveBlockItem` reads them. Ordered (not a
+ * bare Set) so a caller needing the VALUE can iterate, and the canonical key stays first.
  */
-export const BLOCK_DISCRIMINATOR_KEYS = ['template', '_type'];
+const BLOCK_DISCRIMINATOR_KEYS = ['template', '_type'];
 /** Membership form of {@link BLOCK_DISCRIMINATOR_KEYS}, for the two set-test callers. */
 export const BLOCK_STRUCTURAL_KEYS = new Set(BLOCK_DISCRIMINATOR_KEYS);
 /** True for a key that names a block's template rather than holding any of its content. */

package/dist/validation/deletion-checker.d.ts

@@ -15,18 +15,6 @@ export interface DeletionCheckResult {
 }
 /**
  * DeletionChecker finds all references to an entry before deletion.
- *
- * This class provides referential integrity checking by:
- * - Scanning all entries for references to a target ID
- * - Identifying which entries and fields reference the target
- * - Preventing deletion of entries that are still referenced
- *
- * Usage:
- *   const checker = new DeletionChecker(store, idIndex, schema)
- *   const result = await checker.canDelete(targetId)
- *   if (!result.canDelete) {
- *     console.log('Cannot delete:', result.referencedBy)
- *   }
  */
 export declare class DeletionChecker {
     private store;
@@ -35,31 +23,9 @@ export declare class DeletionChecker {
     constructor(store: ContentStore, idIndex: ContentIdIndex, collections: Map<LogicalPath, {
         fields: FieldConfig[];
     }>);
-    /**
-     * Check if an entry can be safely deleted.
-     *
-     * @param id - The content ID to check
-     * @returns Result indicating if deletion is safe and what references exist
-     */
     canDelete(id: string): Promise<DeletionCheckResult>;
-    /**
-     * Find all entries that reference the target ID.
-     *
-     * @param targetId - The content ID to search for
-     * @returns Array of reference info for each referencing entry
-     */
     findReferences(targetId: string): Promise<ReferenceInfo[]>;
-    /**
-     * Scan a single collection for references to the target ID.
-     */
     private scanCollection;
-    /**
-     * Find all occurrences of target ID in entry data.
-     * Returns field paths where the ID was found.
-     */
     private findIdInData;
-    /**
-     * Helper to list all entries in a collection from the ID index.
-     */
     private listEntriesInCollection;
 }

package/dist/validation/deletion-checker.js

@@ -1,18 +1,6 @@
 import { resolveBlockItem } from './field-traversal.js';
 /**
  * DeletionChecker finds all references to an entry before deletion.
- *
- * This class provides referential integrity checking by:
- * - Scanning all entries for references to a target ID
- * - Identifying which entries and fields reference the target
- * - Preventing deletion of entries that are still referenced
- *
- * Usage:
- *   const checker = new DeletionChecker(store, idIndex, schema)
- *   const result = await checker.canDelete(targetId)
- *   if (!result.canDelete) {
- *     console.log('Cannot delete:', result.referencedBy)
- *   }
  */
 export class DeletionChecker {
     constructor(store, idIndex, collections) {
@@ -20,12 +8,6 @@ export class DeletionChecker {
         this.idIndex = idIndex;
         this.collections = collections;
     }
-    /**
-     * Check if an entry can be safely deleted.
-     *
-     * @param id - The content ID to check
-     * @returns Result indicating if deletion is safe and what references exist
-     */
     async canDelete(id) {
         const referencedBy = await this.findReferences(id);
         return {
@@ -33,27 +15,16 @@ export class DeletionChecker {
             referencedBy,
         };
     }
-    /**
-     * Find all entries that reference the target ID.
-     *
-     * @param targetId - The content ID to search for
-     * @returns Array of reference info for each referencing entry
-     */
     async findReferences(targetId) {
         const references = [];
-        // Scan all collections for references
         for (const [collectionPath, collectionDef] of this.collections.entries()) {
             const refs = await this.scanCollection(collectionPath, collectionDef.fields, targetId);
             references.push(...refs);
         }
         return references;
     }
-    /**
-     * Scan a single collection for references to the target ID.
-     */
     async scanCollection(collectionPath, fields, targetId) {
         const references = [];
-        // Get all entries in this collection from the ID index
         const entries = this.listEntriesInCollection(collectionPath);
         for (const entry of entries) {
             try {
@@ -71,20 +42,15 @@ export class DeletionChecker {
                 }
             }
             catch {
-                // Skip entries that can't be read
                 continue;
             }
         }
         return references;
     }
-    /**
-     * Find all occurrences of target ID in entry data.
-     * Returns field paths where the ID was found.
-     */
     findIdInData(data, targetId, schema, pathPrefix = '') {
         const found = [];
         for (const field of schema) {
-            // Inline groups are transparent — recurse into their children at the same data level
+            // Inline groups are transparent (walkFields, ./field-traversal) — recurse at the same level.
             if (field.type === 'group') {
                 found.push(...this.findIdInData(data, targetId, field.fields, pathPrefix));
                 continue;
@@ -94,7 +60,6 @@ export class DeletionChecker {
             if (value === undefined || value === null)
                 continue;
             if (field.type === 'reference') {
-                // Check if this reference field contains the target ID
                 if (Array.isArray(value)) {
                     if (value.includes(targetId)) {
                         found.push(fieldPath);
@@ -122,8 +87,6 @@ export class DeletionChecker {
                 }
             }
             else if (field.type === 'block') {
-                // Handle block fields — real block items are { template, value }, with
-                // nested field values under `value` (resolved by resolveBlockItem)
                 const blockField = field;
                 if (Array.isArray(value)) {
                     value.forEach((item, index) => {
@@ -139,16 +102,11 @@ export class DeletionChecker {
         }
         return found;
     }
-    /**
-     * Helper to list all entries in a collection from the ID index.
-     */
     listEntriesInCollection(collectionPath) {
         const entries = [];
-        // Get all locations from the index
         const allLocations = this.idIndex.getAllLocations();
         for (const location of allLocations) {
             if (location.type === 'entry') {
-                // Check if this entry is in the target collection
                 if (location.collection === collectionPath ||
                     location.collection?.startsWith(collectionPath + '/')) {
                     entries.push({

package/dist/validation/entry-link-validator.d.ts

@@ -1,14 +1,12 @@
 /**
- * EntryLinkValidator validates that entry:ID patterns in body/markdown fields
- * reference existing entries.
- *
- * Returns warnings (not errors) — saves are never blocked by broken entry links.
- * This parallels ReferenceValidator but operates on inline links in text content
- * rather than structured reference fields.
+ * Scans body/markdown/mdx fields for `entry:ID` links and checks that each ID
+ * resolves to an existing entry. Warns rather than blocks — a save is never
+ * rejected over a broken entry link. Parallels `ReferenceValidator`, but for
+ * inline links in text rather than structured reference fields.
  */
 import type { ContentIdIndex } from '../content-id-index.js';
 import type { FieldConfig } from '../config/index.js';
-export interface EntryLinkWarning {
+interface EntryLinkWarning {
     field: string;
     fieldPath: string;
     id: string;
@@ -17,10 +15,5 @@ export interface EntryLinkWarning {
 export interface EntryLinkValidationResult {
     warnings: EntryLinkWarning[];
 }
-/**
- * Validate entry links in body/markdown/mdx fields of the provided data.
- *
- * Scans all markdown and mdx fields for entry:ID patterns
- * and checks that each referenced ID exists in the content index.
- */
 export declare function validateEntryLinks(data: Record<string, unknown>, schema: readonly FieldConfig[], idIndex: ContentIdIndex, bodyContent?: string): EntryLinkValidationResult;
+export {};

package/dist/validation/entry-link-validator.js

@@ -1,26 +1,17 @@
 /**
- * EntryLinkValidator validates that entry:ID patterns in body/markdown fields
- * reference existing entries.
- *
- * Returns warnings (not errors) — saves are never blocked by broken entry links.
- * This parallels ReferenceValidator but operates on inline links in text content
- * rather than structured reference fields.
+ * Scans body/markdown/mdx fields for `entry:ID` links and checks that each ID
+ * resolves to an existing entry. Warns rather than blocks — a save is never
+ * rejected over a broken entry link. Parallels `ReferenceValidator`, but for
+ * inline links in text rather than structured reference fields.
  */
 import { extractEntryLinkIds } from '../entry-link-resolver.js';
 import { findFieldsByType } from './field-traversal.js';
-/**
- * Validate entry links in body/markdown/mdx fields of the provided data.
- *
- * Scans all markdown and mdx fields for entry:ID patterns
- * and checks that each referenced ID exists in the content index.
- */
 export function validateEntryLinks(data, schema, idIndex, bodyContent) {
     const warnings = [];
     // Check body content (for md/mdx entries, body is separate from data)
     if (bodyContent) {
         checkText(bodyContent, 'body', 'body', idIndex, warnings);
     }
-    // Check markdown/mdx fields in structured data
     const markdownTypes = ['markdown', 'mdx'];
     for (const fieldType of markdownTypes) {
         const contexts = findFieldsByType(schema, data, fieldType);

package/dist/validation/entry-type-reference-validator.d.ts

@@ -1,27 +1,22 @@
 /**
  * Validates that every reference field's `entryTypes` names an entry type that
- * actually exists in the resolved schema.
+ * actually exists in the resolved schema — without this, a typo like
+ * `entryTypes: ['parter']` is accepted silently and surfaces later as a
+ * reference picker returning zero results, with nothing pointing at the cause.
  *
- * Without this, a typo (`entryTypes: ['parter']` for `'partner'`) is accepted
- * silently and surfaces much later as a reference picker that returns zero
- * results, with nothing pointing at the cause.
- *
- * This runs after schema resolution rather than at config-validation time on
- * purpose: entry types are declared per-collection in `.collection.json` files
- * on disk, so the set of valid names only exists once a branch's schema has
- * been resolved. `config/validation.ts`'s `ensureReferenceFieldsHaveScope` runs
- * at entry-schema *registration* (entry-schema-registry.ts), before any branch
- * schema exists, and so cannot perform this check.
+ * Runs after schema resolution, not at config-validation time: entry types are
+ * declared per-collection in `.collection.json` files on disk, so the valid-name
+ * set only exists once a branch's schema is resolved. `config/validation.ts`'s
+ * `ensureReferenceFieldsHaveScope` runs at entry-schema registration
+ * (entry-schema-registry.ts), before any branch schema exists, so it can't.
  */
 import type { RootCollectionConfig } from '../config/index.js';
 /**
- * Collect every entry type name defined anywhere in the schema.
- *
- * Entry types are scoped per collection, and the same name may legitimately
- * appear in several collections, so this is a flat set of names: a reference
- * field's `entryTypes` is matched against entries across all collections
- * (see reference-resolver.ts, which filters resolved entries by entry type name
- * without regard to which collection defined it).
+ * Collect every entry type name defined anywhere in the schema, as a flat set:
+ * a reference field's `entryTypes` matches entries across ALL collections, since
+ * the same type name may legitimately appear in more than one (see
+ * reference-resolver.ts, which filters by type name regardless of collection).
+ * @internal Exported for tests.
  */
 export declare const collectEntryTypeNames: (schema: RootCollectionConfig) => Set<string>;
 /**

package/dist/validation/entry-type-reference-validator.js

@@ -1,17 +1,14 @@
 /**
  * Validates that every reference field's `entryTypes` names an entry type that
- * actually exists in the resolved schema.
+ * actually exists in the resolved schema — without this, a typo like
+ * `entryTypes: ['parter']` is accepted silently and surfaces later as a
+ * reference picker returning zero results, with nothing pointing at the cause.
  *
- * Without this, a typo (`entryTypes: ['parter']` for `'partner'`) is accepted
- * silently and surfaces much later as a reference picker that returns zero
- * results, with nothing pointing at the cause.
- *
- * This runs after schema resolution rather than at config-validation time on
- * purpose: entry types are declared per-collection in `.collection.json` files
- * on disk, so the set of valid names only exists once a branch's schema has
- * been resolved. `config/validation.ts`'s `ensureReferenceFieldsHaveScope` runs
- * at entry-schema *registration* (entry-schema-registry.ts), before any branch
- * schema exists, and so cannot perform this check.
+ * Runs after schema resolution, not at config-validation time: entry types are
+ * declared per-collection in `.collection.json` files on disk, so the valid-name
+ * set only exists once a branch's schema is resolved. `config/validation.ts`'s
+ * `ensureReferenceFieldsHaveScope` runs at entry-schema registration
+ * (entry-schema-registry.ts), before any branch schema exists, so it can't.
  */
 import { forEachReferenceField } from '../config/validation.js';
 /**
@@ -59,13 +56,11 @@ const forEachEntryType = (schema, visit) => {
     walk(schema, '');
 };
 /**
- * Collect every entry type name defined anywhere in the schema.
- *
- * Entry types are scoped per collection, and the same name may legitimately
- * appear in several collections, so this is a flat set of names: a reference
- * field's `entryTypes` is matched against entries across all collections
- * (see reference-resolver.ts, which filters resolved entries by entry type name
- * without regard to which collection defined it).
+ * Collect every entry type name defined anywhere in the schema, as a flat set:
+ * a reference field's `entryTypes` matches entries across ALL collections, since
+ * the same type name may legitimately appear in more than one (see
+ * reference-resolver.ts, which filters by type name regardless of collection).
+ * @internal Exported for tests.
  */
 export const collectEntryTypeNames = (schema) => {
     const names = new Set();