Public open source · npm · v0.1.1

Catalog Parity

Compare source and target commerce catalog exports before a migration, integration, or release goes live. Find missing records and field-level drift without connecting production systems.

Public repositoryMIT licensedPublished on npmLocal-only processing
catalog-parity — zsh — 92×24

rxr@commerce ~/migration % npx @rxrcode/catalog-parity@0.1.1 compare source.csv target.csv --key sku --field title --field price

✗ Catalog differences found

Source 3 · Target 3 · Matched 2 · Missing 1 · Extra 1 · Changed fields 1

CHANGED MUG-WHT price        source: "18.50"        target: "19.00"MISSING TOTE-NAT not found in targetEXTRA    CAP-NVY only in target
ExportCompareReview

Verification model

Export. Compare. Review.

Run npx @rxrcode/catalog-parity@0.1.1 --help to use the published CLI without a global install. Catalog Parity compares two exports using a key such as SKU, then checks the fields selected for the release.

Source and target fields can have different names, so an ERP field such as product_code can be mapped to a storefront field such as sku.

Exit code 0 means parity, 1 means differences were found, and 2 means the inputs or command were invalid.

Current capabilities

A focused migration check, ready to automate.

  • CSV and JSON catalog exports
  • Cross-system key and field mappings
  • Nested JSON field comparison
  • Missing, extra, and field-level difference reports
  • Human-readable and JSON output
  • Deterministic, CI-friendly exit codes

Data boundary

Your catalog exports stay local.

The CLI does not upload catalog data, call a commerce platform, or require ERP, PIM, marketplace, or storefront credentials. It reads the files supplied to the command and writes only when an output file is explicitly requested.

Direct platform connections, fuzzy matching, automatic corrections, and synchronization are deliberately outside the v0.1 scope.

Community

Use it on a test export or help shape the next check.

The project is intentionally early. Export examples, mapping use cases, normalization edge cases, documentation improvements, and focused bug reports are useful contributions.

Start a project

Tell us where the workflow breaks.

Choose the kind of problem, add enough context to understand the workflow, and tell us what should be better when it is finished. You do not need a technical specification.

What needs to work better?

Choose the closest fit. You can change this later.
Prefer email? contact@rxrcode.dev