I found that loadCategoryRegistry accepts duplicate category IDs when categories.ts exports a plain array. The existing defineLeafCategories constructor rejects the same entries. Because the loader is used by catalog compilation, a registry can reach compilation with conflicting display metadata for one category identity.
To reproduce with Deno 2, save the following as repro-category.ts in the repository root and run deno run --allow-read --allow-write --allow-env repro-category.ts:
import { defineLeafCategories, loadCategoryRegistry } from "./shared/core/mod.ts";
const leaves = [{id:"demo",displayName:"First"},{id:"demo",displayName:"Second"}];
try { defineLeafCategories(leaves); } catch (error) { console.log("constructor:", String(error)); }
const dir = await Deno.makeTempDir();
try {
await Deno.writeTextFile(`${dir}/categories.ts`, `export const LEAF_CATEGORIES = ${JSON.stringify(leaves)};`);
console.log("loader:", await loadCategoryRegistry(dir));
} finally { await Deno.remove(dir, {recursive:true}); }I get a constructor error (duplicate leaf category id: demo), followed by a successful loader result containing both demo entries with different display names. I expect the loader to reject the duplicate ID as well.
The loader currently parses only z.array(zLeafCategory), which validates individual entries but never checks ID uniqueness. I propose passing the parsed array through defineLeafCategories, reusing its existing uniqueness rule and frozen result. Shape errors should retain the existing file context. Distinct IDs sharing a display label should remain valid.
I searched open and closed issues and PRs for duplicate categories, loadCategoryRegistry, LEAF_CATEGORIES, and duplicate leaf IDs; I found no matching report or fix.
Activity
0No activity yet.