Size Sorter Laravel Package

Technical Evaluation

Architecture fit

• The package remains a narrowly scoped, framework-agnostic PHP domain utility: it maps human-authored size labels ("S/M/L/XL", "170", "75B", furniture dimensions) to a canonical ordinal and sorts by it. That is exactly the shape of logic that leaks into controllers, Blade templates, and Eloquent orderBy clauses in Laravel commerce codebases if left unowned — so there is still a real architectural slot for it.
• 2.1.0 explicitly adds Laravel 13 compatibility, which confirms there is a maintained framework integration surface (service provider / test matrix), not just a bare PHP helper. That strengthens the "Laravel-native" fit but does not change our placement decision: it belongs in the domain/application layer as a value-object or comparator service, wrapped behind our own interface (e.g. SizeOrderResolver), not called directly from controllers or query builders.
• No persistence, no migrations, no queues, no HTTP. The Laravel 13 item is a compatibility statement, not new runtime behaviour. Architecture risk is unchanged and low.
• It complements rather than replaces catalog modeling. We still need a size taxonomy in our own schema (enum or attribute table); the package only supplies ordering semantics.

Integration feasibility

• composer require dragon-code/size-sorter, MIT licensed, PSR-4 autoloaded, effectively zero install footprint. A first working sort is still under an hour of developer time.
• The 2.1.0 release is a minor bump with no declared breaking changes: one compatibility addition plus cosmetic/metadata changes (LICENSE year, README images, banner, preview). Semver hygiene looks reasonable.
• The value is still concentrated in its internal size tables (clothing, height, bra, furniture). Those tables are the asset, not the code. Framing holds: we are adopting a dataset more than a library.
• 2.1.0 is a meaningful maintenance signal — the maintainer is tracking framework releases and merging external PRs (#55 was a community contribution). That partially retires the "abandoned package" concern from the prior assessment. Adoption metrics (low stars/dependents) remain weak, so still treat the README as the contract and validate the API in a spike.
• New churn signal: the project was renamed from "Product Size Sorter" to "Size Sorter" (#52). Repo renames typically leave the Composer package name and PHP namespace intact, but this must be verified before we write it into a design doc — a namespace change would be a hard breaking change disguised as a minor.

Technical risk

• Correctness risk is product risk. Unchanged and still the dominant risk: a mis-ordered size filter is a conversion and trust defect. Regional and vanity sizing (EU vs US vs UK, women's vs men's, kids') is where these libraries typically degrade, and no part of 2.1.0 addresses data quality.
• Laravel 13 support implies a PHP floor bump. Framework-version support in this ecosystem usually tracks PHP 8.2/8.3+. If our oldest supported app is on an earlier PHP or Laravel major, we may not be able to take 2.1.0 — and staying on 2.0.x means staying off the maintained line. Confirm both constraints before pinning.
• Rename/naming risk (new). Verify the Composer package name, PHP namespace, and PSR-4 root did not change in #52. If the package name changed, our composer.json entry, lockfile, SBOM, and any allowlist entry all need updating; if the namespace changed, every use statement breaks. Budget a 30-minute check, not a surprise.
• Key-person and bus-factor risk is marginally reduced (external PR merged, bot-driven housekeeping, active in the Laravel 13 cycle) but structurally unchanged: single maintainer, negligible downstream usage, no community pressure to keep size semantics current as brands drift. MIT mitigates — we can fork — but the fork becomes ours.
• Prior metadata anomaly is now resolved. The previously flagged anomalous last-release date should be re-read as an artifact; 2.1.0 establishes real recent activity. Drop that concern, but keep the fixture-test guardrail, because activity does not equal size-table accuracy.
• Opportunity signal remains weak. Nothing here is a differentiator; it is table stakes plumbing. Fund it as a small enabler, not an initiative.
• Risk remains asymmetric in our favor: worst case we extract the size tables, drop the dependency, and keep our adapter.

Key questions

1. Did #52 change the Composer package name or PHP namespace, or only the repository/product display name? (Blocking for pinning.)
2. What is the minimum PHP version for 2.1.0, and which Laravel majors are in the CI matrix? Does that cover our oldest supported app?
3. Which size systems do we actually sell into (clothing only? shoes? bra? furniture dimensions?) and do the built-in tables cover each, or only the README examples? (Unchanged — 2.1.0 adds no data.)
4. What does it do with an unrecognized size string — throw, return null, or sort arbitrarily? Determines our error-handling design.
5. Is the Laravel integration a first-class supported surface (documented provider/facade, covered by the CI matrix) or incidental to the compatibility bump?
6. Where does ordering currently happen (DB, PHP, front end), and is the database the system of record for sort order?
7. Do we need a persisted sort key per size for query-time ordering at catalog scale?
8. What is the maintainer's stated support policy, and are we willing to fork?

Integration Approach

Stack fit

• Native for a Laravel monolith or modular monolith on PHP 8.x; with 2.1.0 the package now declares Laravel 13 compatibility, so it is viable across our current and next framework major — subject to the PHP floor check.
• Because it is framework-agnostic underneath, it also works in a separate catalog/search service or a queue worker that reindexes products — useful if we later split catalog out of the monolith.
• It does not integrate with Eloquent directly. Ordering a query by size requires either a computed sort column or in-PHP sorting after fetch. This remains the main design decision, not the library choice.

Migration path

1. Pin and verify (half a day): require ^2.1, confirm the package name and namespace are unchanged by the rename, confirm PHP/Laravel constraints against our app matrix, and read the 2.0 → 2.1 diff. Low risk, but do it before the spike so we do not spike the wrong artifact.
2. Spike (1–2 days): feed it 200–500 real size labels pulled from the production catalog and diff its ordering against current behaviour and merchandising expectations. This is the go/no-go gate and 2.1.0 does not change it.
3. Adapter: define SizeOrderResolver in our domain layer with resolve(string $size, SizeSystem $system): int. Implement over the package. No other code imports the package namespace — this is also what insulates us from the rename.
4. Taxonomy alignment: map our existing size enum/attribute values to the package's expected vocabulary explicitly, in one config file. Do not rely on string coincidence.
5. Pilot: apply to a single category (e.g. apparel tops) behind a flag; compare filter and PLP ordering against control.
6. Expand: add categories one at a time, each with its own fixture set.
7. Optionally contribute missing systems upstream rather than growing a private fork. 2.1.0 shows the maintainer merges external PRs, which modestly improves the odds this route works.

Compatibility

• Verify the PHP constraint for 2.1.0 against our oldest app, and whether 2.0.x remains installable if we cannot meet it.
• Confirm case sensitivity, whitespace handling, and unicode ("XXL" vs "2XL", "80B" vs "80 B").
• Confirm behaviour for numeric sizes stored as strings ("170" vs "170cm") and for half sizes.
• Mixed systems within one category (US and EU labels coexisting) must be resolved before calling the sorter, not by it.
• Re-run composer audit and SBOM refresh as part of the bump; treat the rename as a metadata change to reconcile in our dependency register.

Sequencing

• Do this after the size taxonomy is normalized in the catalog schema and before building size-aware filtering, faceting, or "shop by size" navigation. Building filters first means rewriting them.
• The 2.1.0 bump is not urgent on its own merits (it buys us Laravel 13 readiness and continued maintenance, not capability). Fold it into the next dependency-maintenance window rather than forcing a special release.
• Independent of and parallel to search infrastructure work; no shared dependencies.

Operational Impact

Maintenance

• Pin to an exact minor version (^2.1 at minimum, ideally 2.1.*) and re-pin deliberately. The low dependent count still means breaking changes can ship with thin migration notes.
• Add the package to dependency review with a fork escape hatch: keep the adapter thin so replacing the dependency is a one-file change.
• Expect the size tables to drift as merchandising adds categories; own extensions as upstream PRs (now demonstrably viable) or a local config overlay.
• Reconcile the rename in our internal package inventory, SBOM, and any dependency allowlist so future audits do not flag it as an unknown artifact.

Support

• Community-only, no SLA, single maintainer — but now with visible external contributions and framework-major tracking. That is reassuring, not a guarantee; internal ownership must still be explicit (assign to the catalog/platform team).
• Practical mitigation unchanged: comprehensive fixture tests in our repo covering every size system we sell. Those tests, not the library, are our real safety net.

Scaling

• Compute cost is negligible: an in-memory comparator over a list of sizes, executed per request or per reindex. It will never be a bottleneck. 2.1.0 adds no runtime cost.
• The scaling concern is query-time ordering, not CPU. Sorting a paginated Eloquent query by size requires a persisted sort key. Recommendation stands: compute size_order once at product/variant write time with this package, store it as an indexed integer column, and order in SQL — keeping the dependency off the hot read path.
• Recompute the column on catalog import and on package upgrades (including 2.1.0), behind a backfill job with a diff report before promotion.

Failure modes

• Unrecognized size → exception on catalog import or, worse, arbitrary ordering in production. Guard: validate on ingest, quarantine unknowns, alert.
• Silent mis-ordering after an upgrade — highest-severity failure, invisible without fixture tests. Mitigate with a golden-file ordering test in CI, and run it against 2.1.0 before pinning.
• Mixed or ambiguous systems producing plausible-but-wrong order that passes casual QA and fails customers.
• Rename-induced build breakage if the package name or namespace shifted in #52 — caught at pin time, not in production, if we verify first.
• Constraint lockout if 2.1.0's PHP/Laravel floor exceeds our oldest app, leaving us on an unmaintained line.
• Import pipeline outage if the sorter is called synchronously and throws on a single bad row — batch-isolate instead.
• Abandonment — mitigated by MIT, the adapter boundary, and the improved-but-unproven activity signal.
• None of these are availability failures; all are data-integrity or build-integrity failures. That argues for putting this logic in the import/validation path with strong observability rather than scattered through the app.

Ramp-up

• Low. A mid-level Laravel developer can integrate and test this in half a day; adapter plus fixture harness is 1–2 days of real work, with a small increment for the 2.1.0 verification steps.
• The genuine ramp-up cost is domain knowledge, not code: someone must own the mapping between our size taxonomy and each regional system, and that person is a merchandising stakeholder, not an engineer. Budget their review time into the pilot.
• Recommend a short internal note documenting: which systems are supported, who owns the tables, the pinned version, and the upgrade procedure (bump → verify rename/constraints → reimport → diff → promote).