Product Decisions This Supports
- Where the data-quality gate sits in the catalogue pipeline. This package answers exactly one question — is this a structurally valid GTIN (8/12/13/14 digits, correct Modulo-10 check digit) — which makes it a cheap guardrail at the point of entry: supplier self-serve onboarding forms, bulk CSV/feed imports, marketplace or PIM ingestion, and barcode scan capture. The product decision it unlocks is "reject at ingest and quarantine failures" rather than absorbing correction cost downstream in listings, orders, and fulfilment exceptions.
- Build vs. buy for a commodity primitive. The logic is a published GS1 algorithm, the package is MIT-licensed and tiny, and since v1.0.1 it is genuinely framework-agnostic at runtime. So the trade-off is not licence cost — it is whether you want an unmaintained third-party dependency (last release January 2021, single maintainer, zero dependents) on a catalogue-critical path. Buying buys speed in discovery; vendoring ~100 lines of MIT code buys durability. Make the call explicitly and record it in the dependency register either way.
- Scoping the promise honestly. It validates format and check digit, full stop. It does not confirm the GTIN is registered with GS1, that the company prefix belongs to the supplier, or that the identifier is unique in your catalogue. This lets you sell the feature internally as "format validation," and keeps registry lookup, prefix-ownership checks, and catalogue dedupe as separately estimated roadmap items rather than implicit promises.
- Canonical GTIN length and normalisation policy. A GTIN-12 zero-pads to a GTIN-13 and is the same product; without a decision now, your uniqueness index will admit the same product twice under two lengths. This is a product/data-model decision (14 is the conventional GS1 answer) that must be made alongside adoption, not after the first duplicate listing.
- Supplier onboarding quality reporting. Structured logging of rejects (supplier id, raw value, reason) turns validation failures into a data-quality report — "38% of this supplier's feed has bad check digits" — which is the evidence base for supplier scorecards, feed remediation SLAs, and whether onboarding friction is the bottleneck or the supplier's data is.
- Realistic fixtures for seeding and QA. The generate path produces valid GTINs for seeders, demos, and negative-path tests without touching a real supplier feed — underrated for demo environments and for proving the rule actually rejects.
When to Consider This Package
Adopt when:
- You are on PHP (Laravel or otherwise) and need GTIN/UPC/EAN format plus check-digit validation at one or a few ingestion boundaries.
- The scope is deliberately narrow: reject malformed barcodes before they hit the catalogue table. You are not promising verification, registration, or uniqueness.
- You can wrap it behind your own interface (a
GtinValidator contract, a Laravel validation rule) so no controller, import mapper, or artisan backfill command calls it directly.
- You accept the maintenance profile: pin
^1.0, verify on a bare PHP install that no stray Illuminate\* runtime reference survived the dev-dependency move, and note the vendoring fallback in your dependency register.
Look elsewhere — or build the ~100 lines in-house — when:
- You need GS1 registry lookup, company-prefix ownership, GS1 Digital Link resolution, SSCC/GLN or other identifier types, or barcode rendering and scanning. None of that is here.
- You need an actively maintained, security-audited dependency on a long-lived critical path. A single-maintainer package with no releases since January 2021 should not be the only thing standing between a supplier feed and your catalogue.
- Your stack is not PHP, or your ingestion is a queue worker or CLI container with a slimmed vendor tree where an undeclared framework dependency is a production incident rather than a metadata curiosity.
- Catalogue-wide uniqueness, deduplication, and canonical-length normalisation are in scope — those are yours to build; the package cannot help and should not be misread as helping.
- You cannot enforce string-typed handling end to end. Any
int cast, bigint column, or spreadsheet round-trip destroys leading zeros; if the surrounding system cannot guarantee strings at the form, the cast, the migration, and the model, adoption will produce false results rather than protection.
How to Pitch It (Stakeholders)
To executives (one paragraph). Suppliers send us barcodes; a meaningful share of them are structurally wrong, and today we find out downstream — in listings, in orders, in fulfilment — where fixing them costs far more than rejecting them on arrival. This is a small, MIT-licensed PHP library that checks the standard GS1 check digit for the four common GTIN formats. It costs us hours, not a sprint, to wire in behind our own interface, and it moves a whole class of data errors to the front door where the supplier can be told immediately and the fix costs nothing. It is commodity algorithmic logic, not a vendor commitment; we pin the version, wrap it so we can replace it in one class, and we deliberately do not sell it as "verified product data" — registry lookup and duplicate detection remain separately scoped roadmap work.
To engineering (the ask). Treat it as a primitive, not a framework. Bind it behind an App\Support\Gtin\GtinValidator contract and use a Laravel validation rule object so call sites never touch Gtin::make(). Enforce strings at every layer — form rule, cast, migration (string('gtin', 14)), model mutator — because leading zeros are the entire failure mode. Apply the rule on all three write paths: the FormRequest, the bulk import handler, and the backfill artisan command that runs with events off and bypasses both. Accumulate per-row import failures instead of aborting at row three, and log the raw rejected value. Verify the package on a bare PHP install before trusting the dev-dependency fix, then pin and move on. If we ever regret the dependency, the swap is a one-class change plus a container binding — but only if we resisted calling the package directly early on.