Size Sorter Laravel Package

Product Decisions This Supports

• Build vs. buy on a boring-but-recurring problem. Every commerce surface that displays a size eventually needs a canonical order (XS < S < M < L < XL < XXL, 38 < 40 < 42, 5'9" < 5'11"). Teams typically hand-roll a lookup table, discover it breaks on one-piece sizes, half-sizes, bra sizes (34B vs 36A), or regional labels, and rebuild it. This package makes that a one-line dependency instead of a maintained internal artifact.
• Data model: normalize at read time, not at write time. Because sorting is a presentation concern here, you can keep merchant-entered size strings exactly as-is in the database and derive ordering in code. That avoids a migration + backfill + vendor-data-cleanup project, and avoids forcing suppliers to conform to your enum. This is the single most consequential decision the package de-risks.
• PLP / filter UX roadmap. Size filter chips, facet ordering, and "shop the size run" navigation are conversion-sensitive surfaces. Unsorted size filters (putting XL before L, or 42 before 40) read as broken to customers in apparel and footwear. This is a low-cost way to fix a visible polish gap in the catalog experience.
• Category expansion decisions. The package covers clothing, height, bra size, and furniture size in one abstraction. That lowers the marginal cost of expanding into adjacent verticals (furniture, intimates, kids' sizing, uniforms, rentals) where a single "size" column previously wouldn't have generalized.
• Internal tooling and ops. Warehouse picking lists, packing slips, returns triage, and inventory exports all benefit from deterministic size ordering — often an unowned papercut that ops teams work around manually.
• Roadmap scoping signal (negative). The low ecosystem signal — 39 stars, zero dependents — should tell you this is a utility, not a platform. It does not justify a "sizing platform" epic, a data team, or a size-chart service. Treat it as commodity glue and keep sizing investment focused on fit guidance, conversion, and returns reduction, which is where customer value actually lives.
• Maintenance signal (updated, 2.1.0). The maintainer shipped Laravel 13 compatibility promptly in a minor release — a small but real counterweight to the "single maintainer, may be abandoned" risk. It does not change the conclusion (still pin and isolate), but it moves the package from "possibly stale" to "actively tracked against framework majors."
• Buy signal. MIT license, no runtime service, no data egress, tiny API surface. The cost of trying it is an afternoon; the cost of owning a bespoke size-ordering table is years of intermittent bug tax.

When to Consider This Package

Adopt when:

• You are on PHP/Laravel and size ordering is genuinely presentational — sort order, filter order, display grouping — not the basis of business logic.
• Your catalog already contains messy, human-entered size labels from multiple suppliers and you cannot enforce a schema.
• You need multi-category coverage (apparel + footwear + furniture + height) rather than one narrow enum.
• Your team is small and the alternative is an untested internal helper with no owner.
• You need it now and cheaply; the integration cost is trivial and reversible.
• You are on a current framework major. 2.1.0 adds Laravel 13 support, which is the release cadence you want to see from a small utility; older tags may not track your framework.

Look elsewhere (or build/wrap) when:

• You need conversions, not sorting. US ↔ EU ↔ UK ↔ JP mapping, vanity sizing, or brand-specific charts require an authoritative, maintained dataset. Sorting ≠ sizing intelligence.
• You need measurements or fit guidance. Chest/waist/inseam data, size recommendations, fit predictors, and returns-reduction features are a different product category entirely.
• Correctness is regulated or high-stakes. Uniforms, medical garments, PPE, or safety equipment need validated size standards with a vendor who will sign something.
• You need maintenance guarantees. Laravel 13 support is encouraging but does not constitute an SLA — one maintainer and zero dependents still means no committed roadmap. If you cannot tolerate an abandoned dependency, vendor the logic behind an internal interface (see below) or copy the mapping.
• You are polyglot or non-PHP. A cross-language catalog service should not encode ordering rules in PHP alone; put ordering in the data layer or a shared spec.
• You need inclusive/extended ranges with rigor (tall, petite, plus, kids' age-based sizing). Verify coverage against your actual assortment before committing — a package that mis-sorts your long tail is worse than an honest custom table.

Watch item introduced in 2.1.0: the project was renamed from Product Size Sorter to Size Sorter. Confirm the Composer package name, namespace, and import paths you pin against — a rename can mean a new package identity, a redirect, or a fork-worthy split. Verify before you write it into a dependency manifest, and record the exact version in your lockfile.

Mitigation regardless of decision: wrap the package behind a thin internal SizeOrder interface with your own test fixtures built from real catalog data. That preserves the buy decision while making a future swap — or an upstream rename — a one-file change.

How to Pitch It (Stakeholders)

To executives: This is a cheap, low-risk fix for a class of small but customer-visible defects — size filters and size runs that appear out of order on category pages. It is MIT-licensed, adds no infrastructure, no vendor relationship, and no data leaving our systems. Expected effort is roughly a day of engineering; the alternative is maintaining our own size-ordering table indefinitely with no clear owner. It also lowers the cost of expanding into adjacent categories like furniture or intimates, where our current single "size" field doesn't generalize. The project shipped a maintenance release this cycle adding current framework support, so it is being kept alive — but it is still a small, single-maintainer utility, and we should treat it as commodity glue rather than a strategic dependency.

To engineering: A small, dependency-free PHP utility that converts heterogeneous size labels into a comparable value, so you can sort collections and order facets without a hand-maintained lookup table. It handles clothing, height, bra, and furniture size families. 2.1.0 is a maintenance release: Laravel 13 compatibility plus cosmetic and licensing housekeeping — no API changes, no deprecations, no behavioral changes to the sorting logic. Two things to plan around: (1) the project was renamed from Product Size Sorter to Size Sorter, so verify the Composer package name and namespace before pinning; and (2) adoption is still minimal (39 stars, no known dependents), so we pin the exact version and isolate it behind a single internal adapter with tests driven by real catalog strings. Remember it does sorting only — no unit conversion, no measurement data, no fit logic. Assume we may outgrow it; design the seam now so replacing it later costs an hour, not a sprint.