Repository navigation
feat(shared-data): item and variant schemas, model_key helpers (#1149) - #1167
Conversation
Add the Item / variant key rules from the design doc (#1129, section 4): composeModelKey and splitModelKey (model_key = item_key:variant_key), isItemKey / isVariantKey / isModelKey / isSizedVariantKey, and the ItemSchema, VariantSchema and VariantSourceSchema zod contracts. The helpers are zod-free and exported from both the root entry and @repo/shared-data/rules. Tests round-trip every key in the importer fixtures. Nothing consumes them yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… rule (#1149) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
If your organization's extra usage balance is empty, an organization admin can add extra usage credits at claude.ai/admin-settings/usage. If its monthly spend limit was reached, an admin can raise it on the same page. If neither applies, contact Anthropic support.
Once extra usage is available, someone with write access to this repository can comment @claude review on this pull request to trigger a review.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 20 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…1149) PO decision: the key shape accepts '_' in all three segments, because the normalizer's slugify keeps it and real keys carry it. Empty segments (e.g. samsung::unknown) stay rejected. The design doc's 7.3 inventory regex now matches the helpers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Closes #1149
Task 3 of the Item / variant / listing model (#1129, design doc
Docs/Proposals/2026-10-27-item-variant-listing-model.md, sections 4 and 10). Pure library code; nothing consumes it yet.What changes
packages/shared-data:rules/model-key.ts(zod-free, exported from the root entry and from@repo/shared-data/rules):splitModelKey(modelKey)returns{ itemKey, variantKey }, ornullwhen the key is not in thebrand:model:variantshape.composeModelKey(itemKey, variantKey)buildsitem_key:variant_keyand throws aRangeErroron an invalid part or a key over 200 characters.isItemKey,isVariantKey,isModelKey,isSizedVariantKey(^\d+(gb|tb)$, the multi-size rule of 4.2 / 7.2),UNKNOWN_VARIANT_KEY, and the*_PATTERNregexes._allowed.variant_keyis the literal third segment (256gb,1024gb,standard,unknown, and later256gb-cellular). Apple screen and case sizes stay in the Item key (apple:ipad-pro-m5-11).schemas/item.schema.ts:ItemSchema: arate.itemsrow per the 4.3 DDL. Like the table,item_keyhas no shape check, because legacy keys still get an Item.VariantSchema:MasterProductSchemaplus nullableitem_id,variant_keyandsort_order. It refines thatvariant_keyequals themodel_key's third segment when the key is well formed.VariantSourceSchema: theproducts.variant_sourcevalues.ItemKeySchema,VariantKeySchemaandModelKeySchema.Tests
pnpm --filter @repo/shared-data testadds a new 8/8 step:apps/importer/src/shopee/__tests__(155 today, read at test time) round-trips through split and compose. This covers Apple size-keyed lines,:unknown, earbuds, Garmin and Apple watches, and1024gb._), so a fixture key the helpers would reject fails the test instead of being skipped.Also checked locally:
@repo/crawlersbuild,test:dist, and@repo/webtypecheck.Review
variant_keynote, the test comments, and the fixture scan's strictness._, yetslugifyin the normalizer keeps it, as inasus:vivobook-x1504_va:512gb(Codex rated this P1)._in all three segments.samsung::unknown, from a title with no model) stay rejected. The normalizer side is tracked on importer: item-first matcher (match_item), item_key/variant_key, nullable variant behind a flag #1151.🤖 Generated with Claude Code
📌 TL;DR
Introduces a new Item/Variant data model with strict
model_keyparsing/composition utilities and Zod schemas to enforce thebrand:model:variantstructure, ensuring data integrity across the shared data package.🎯 Type of Change
🔍 Changes Walkthrough
packages/shared-data/src/rules/model-key.tssplitModelKey,composeModelKey,isItemKey, etc.) to parse and validate thebrand:model:variantkey structure. Enforces length limits and segment shapes.packages/shared-data/src/schemas/item.schema.tsItem,Variant, and key types. Includes asuperRefinecheck onVariantSchemato ensurevariant_keymatches the third segment ofmodel_key.packages/shared-data/src/rules/index.tsmodel-keyutilities to make them available via the@repo/shared-data/rulesentry point.packages/shared-data/src/schemas/index.tsitem.schemato make Item/Variant schemas available via the main package entry.packages/shared-data/src/index.tsmodel-keyrules from the root entry point.packages/shared-data/src/__tests__/shared-data.test.ts📊 Architectural Flow
flowchart TD subgraph "Input" A[Raw model_key string] end subgraph "Rules: model-key.ts" B{isModelKey?} C[splitModelKey] D[composeModelKey] E[isItemKey / isVariantKey] end subgraph "Schemas: item.schema.ts" F[ItemSchema] G[VariantSchema] H[superRefine: Check variant_key consistency] end A --> B B -->|Valid| C B -->|Invalid| I[Return null] C --> J[ModelKeyParts: itemKey, variantKey] K[itemKey] --> E L[variantKey] --> E E -->|Valid| D D --> M[Composed model_key] N[Item Data] --> F O[Variant Data] --> G G --> H H -->|Uses splitModelKey| C H -->|Pass| P[Valid Variant] H -->|Fail| Q[Validation Error]