Properties Laravel Package

Technical Evaluation

Architecture fit. vanilo/properties is the attribute/property sub-system of the Vanilo e-commerce suite for Laravel — it supplies Property and PropertyValue models plus contracts for modeling product attributes (color, size, material, numeric specs) and their typed values. It is not a standalone product: it is one node in a contract-first, component-based framework assembled through konekt/concord, which registers models/contracts into Laravel's service container so they can be swapped. Architecturally this fits any Laravel application that already adopts (or intends to adopt) the Vanilo family of packages — products, properties, cart, checkout, channels, pricing. It does not fit a non-Vanilo stack cleanly, because the value proposition is interoperability with the sibling modules (properties exist primarily so products can carry structured attributes that feed catalog filtering, PDP specs, and faceted search).

Integration feasibility. Feasible for a Laravel team already committed to Vanilo or evaluating it. The practical install path is vanilo/framework (which pulls vanilo/properties transitively) rather than installing vanilo/properties in isolation — hence the misleading "0 dependents": direct Composer dependents are near-zero because consumption is transitive. Installing the subpackage alone is technically possible but leaves you to wire the Concord module registration, product relationship bindings, and migrations yourself.

Technical risk.

• Bus-factor / maintainer risk: Vanilo is effectively a small-team/lead-maintainer project. The 11 stars on this subpackage are not a signal of quality (the parent repo is materially larger), but they do indicate a thin community surface for issue triage on this module specifically.
• Framework coupling: the Concord contract/registration model is powerful but non-obvious; misregistration produces confusing runtime errors rather than compile-time failures.
• Version matrix: Laravel/PHP support windows track the parent suite, so an application on an older Laravel minor can be pinned to an older properties release; the upgrade cadence follows Vanilo's release train, not Laravel's.
• Low "opportunity" score (32/100) reflects ecosystem gravity, not code quality — there is no large third-party integration ecosystem to lean on.

Key questions.

1. Is the target application already on Laravel and, more specifically, already on (or committed to) Vanilo, or is this an isolated "add attributes to products" need?
2. Which Laravel/PHP versions must be supported, and does the pinned Vanilo release train cover them?
3. What is the attribute model — flat key/value, typed properties with options, or full EAV with per-channel/per-locale values? Does the module's property-type set cover required types (select, multiselect, number, date, boolean)?
4. How will attributes be consumed downstream — PDP rendering only, or faceted search/filtering requiring a search index (Meilisearch/OpenSearch/Elasticsearch)?
5. Do we need admin UI (Vanilo's admin is a separate package) and an API surface (Vanilo's API resources are also separate)?
6. Who owns upgrades and security patching of a transitively-pulled dependency with a thin direct-consumer base?

Integration Approach

Stack fit. Good fit for a Laravel monolith or modular monolith where the catalog is a first-class domain and the team is comfortable with service-container-driven contract swapping. Poor fit for polyglot stacks, headless-only architectures requiring a stable, versioned attribute API independent of PHP, or teams expecting a turnkey platform (Shopware/Magento-style) rather than an assemble-it-yourself framework.

Migration path.

1. If no Vanilo presence: introduce vanilo/framework in a branch, run migrations in a disposable database, and confirm the product + properties tables land as expected.
2. If an existing catalog schema exists (e.g., product_attributes columns or a bespoke EAV table): do not rip-and-replace. Stand up Vanilo properties alongside, define property types, backfill values via a one-off artisan command, then cut read paths over module-by-module.
3. If Vanilo is already present: this is a version-bump exercise — reconcile vanilo/properties with the pinned vanilo/framework and konekt/concord versions, re-run migrations, and verify no contract overrides were shadowed.

Compatibility.

• Pin the whole Vanilo family to a single release train; mixed minor versions across sibling modules are the most common integration failure.
• Verify the konekt/concord version required by properties matches the one the application bootstraps.
• Audit any locally overridden contracts (custom Property model, custom PropertyValue) — Concord swaps are global, so an override intended for one module can silently change behavior in another.
• Confirm DB support (MySQL/PostgreSQL) against the module's migration expectations, particularly around JSON/enum columns if used for option sets.

Sequencing.

• Phase 0 — spike (1–2 sprints): sandbox Laravel app, install framework, model 5–10 representative attributes, validate property types, confirm admin and API surfaces exist or must be built.
• Phase 1 — data model sign-off: agree the attribute taxonomy, typing, and locale/channel scoping with product/catalog owners before writing migrations.
• Phase 2 — product binding: wire properties to the product model, expose read APIs, render PDP specs.
• Phase 3 — search integration: index property values into the search backend; validate facet counts and filter correctness.
• Phase 4 — admin/ops tooling: property CRUD, import/export, and catalog-ops runbooks.
• Phase 5 — cutover and decommission of legacy attribute storage.

Operational Impact

Maintenance. Recurring cost is low in code volume but non-trivial in upgrade coordination: the module moves with the Vanilo release train, which moves with Laravel's. Budget a recurring dependency-upgrade task each Laravel minor and each Vanilo minor. Because consumption is transitive, version drift is easy to miss until a composer update surfaces it.

Support. Community/GitHub-issues support with a small maintainer base; no vendor SLA. For a revenue-bearing catalog, assume internal ownership of the module's behavior — read the source, vendor a fork if needed (MIT permits it), and keep a patching path. Do not plan on upstream turnaround for niche defects.

Scaling. The properties model is EAV-adjacent: product → property values → property definitions. That shape is fine for correctness and admin ergonomics but degrades on high-cardinality reads — expect N+1 hazards when hydrating PDPs and heavy joins when filtering by multiple property values. Mitigations: eager-load aggressively, denormalize a flat "spec sheet" projection for read paths, and treat the search index (not the relational store) as the filtering surface for catalog browse. Writes are low-volume (catalog ops), so write scaling is rarely the constraint; read and index-freshness are.

Failure modes.

• Concord misregistration → container resolves the wrong model class; symptoms appear far from the cause.
• Migration re-entrancy → properties migrations assume a clean Vanilo baseline; partial installs leave orphaned tables.
• Contract shadowing → a custom model override in one module changes behavior in another.
• Index staleness → property edits in admin not propagated to search, producing incorrect facets.
• Version skew → sibling Vanilo modules at mismatched versions causing subtle contract incompatibilities.
• Abandonment risk → upstream goes quiet; the module is small enough to fork, but that must be an owned contingency, not a hope.

Ramp-up. Expect 1–2 weeks for a Laravel-fluent engineer to become productive with Concord and the contract-override idiom, plus the same again to internalize Vanilo's module boundaries (properties vs. products vs. channels vs. pricing). The domain modeling itself — deciding which attributes are typed properties versus first-class columns — is the higher-leverage learning and deserves product/merchandising input, not just engineering judgment. Onboarding cost is modest; the real investment is governance: a documented attribute taxonomy, a version-pinning policy for the Vanilo family, and a named owner for upgrades.