Reviews For Laravel Laravel Package

Technical Evaluation

• Architecture fit: This remains a Composer-based Laravel/PHP package in the Roundly ecosystem, but 1.2.0 is a feature release with breaking behavior changes, not maintenance-only. It introduces a resource layer for review rendering: ReviewAuthorResource and ReviewableResource wrap the related model and emit {id, type} by default, with new config keys reviews.resources.author and reviews.resources.reviewable allowing substitution with custom JsonResource subclasses. The package now owns part of the API serialization contract for reviews rather than just exposing models.
• Integration feasibility: Feasible for existing Roundly applications, but no longer a drop-in patch. Two things require deliberate work: (1) the serialized shape of author.type / reviewable.type changes from FQCN (App\Models\User) to class basename (User), which is a breaking API contract change for any client parsing that field; (2) new configuration surface must be published/merged and validated. Swap-in custom resources are the supported extension point, so teams needing the old shape (or a name/avatar/title) have a clean path, but must implement and register a resource subclass.
• Technical risk: Moderate to high for consumers with public or third-party API clients. The type-value change can silently break mobile apps, front-end consumers, or stored payloads that match on the full class name. Behavior also changes for orphaned relations: author / reviewable now render null when the related row is gone (both keys always present), which differs from prior implicit behavior and can break non-null assumptions. The eager-loading change is a double-edged sword: ReviewCollection and single-resource rendering of loaded responses now issue one query per morph type, but code paths constructing new ReviewResource($review) or ReviewResource::collection() manually will incur N+1 queries unless author and reviewable are eager-loaded. Config validation now throws InvalidConfigurationException naming the offending key, which is good failure clarity but a new startup/runtime failure surface for misconfigured apps. Dev-only testing ^1.6 and CI tmpfs changes are irrelevant to production runtime.
• Key questions: Which consumers parse author.type / reviewable.type, and can they tolerate User instead of App\Models\User? Do we need to ship custom resources via reviews.resources.* to preserve the existing contract, and if so, is a name/avatar/title required now? Are there code paths rendering ReviewResource without the collection (queues, exports, Blade, API resources composed manually) that need explicit ->load('author', 'reviewable')? Does any client depend on the related model being present rather than null? What Laravel/PHP versions does 1.2.0 support, and does it still allow the previously required package-toolkit ^1.3.0, enums ^1.1.0, media-library ^1.1.2 constraints? Where are config values cached, and how will InvalidConfigurationException be caught at boot? What is the rollback path if the serialized shape breaks a downstream client after deploy?

Integration Approach

• Stack fit: Best fit for Laravel applications already consuming the Roundly package family and exposing reviews through this package's resources. Teams outside the ecosystem should treat 1.2.0 as a new integration point, since it now defines a JSON contract and a config surface, not just a model helper.
• Migration path: Upgrade in a branch, publish/merge the new reviews.resources.* config keys, and decide explicitly per key: accept the new default ({id, type} with class basename) or register a custom JsonResource to preserve or extend the shape. Diff the serialized output of a review payload before and after (including a soft-deleted/missing author case) and treat any difference as a contract change requiring consumer sign-off. Then audit manual ReviewResource construction for missing eager loads, run the test suite, and update snapshots/contract tests.
• Compatibility: Primarily governed by Composer constraints plus the new config schema. Verify Laravel/PHP support and that prior sibling constraints still resolve. Note the behavioral compatibility gap: no API signature breakage is described, but the serialized payload is not backward compatible for type values. Blank config values fall back to defaults, so empty strings are safe; non-JsonResource values fail fast.
• Sequencing: (1) Inventory all consumers of author.type / reviewable.type and any stored payloads. (2) Decide default vs. custom resource per key and implement custom resources if the old shape must hold. (3) Add config and verify config:cache behavior. (4) Add explicit eager loads on manual render paths. (5) Run contract/snapshot tests and a staging deploy with representative data, including a review whose author row was deleted. (6) Publish consumer-facing change notes before production rollout, coordinating with other Roundly package updates.

Operational Impact

• Maintenance: Higher than the previous maintenance-only cadence: this release adds configuration and an extension API (reviews.resources.*), so teams now own resource classes, config values, and their upgrade path. Watch for follow-up patches around null handling and eager loading. Dependency hygiene continues (testing ^1.6 is dev-only).
• Support: The dominant support theme shifts from Composer conflicts to serialization contract questions ("why is type User now?", "why is author null?", "why is my endpoint slow?"). Document the chosen resource configuration and the null-for-missing-relation policy. InvalidConfigurationException messages name the key, which shortens triage; ensure boot-time failures surface in deploy logs rather than at first request.
• Scaling: The collection-level eager loading (one query per morph type across reviews and their loaded responses) is a net improvement for list endpoints. The risk is inverse: any manual ReviewResource instantiation without eager loading reverts to a query per review, which can regress performance sharply at volume. Confirm morph-type query counts on review-heavy pages and monitor query volume after deploy.
• Failure modes: Broken downstream clients from the type change; null-pointer or rendering errors where author / reviewable were assumed present; InvalidConfigurationException at boot from a bad or non-JsonResource config value (including a stale cached config); N+1 query regressions on manual render paths; and unexpected query growth on collections with many responses per review across multiple morph types. Rollback is a package version revert plus config revert, but note that reverting re-changes the serialized shape — coordinate rollback with consumers. Validate in staging with deleted-relation fixtures before production.
• Ramp-up: Low for Laravel teams comfortable with API Resources and config publishing; moderate for those new to the Roundly family, who now must learn both the sibling package constraints and the review resource extension model. Budget a short enablement session on the config keys and eager-loading expectations before the first upgrade.