Single Table Inheritance Laravel Package

Technical Evaluation

Assessment basis: This is a first-pass evaluation built from the v1.1.0 release notes only. No repository metadata, dependency manifest, test coverage data, or downstream consumer inventory was supplied (the input data set was empty). Conclusions below are scoped to what the release notes state and are flagged where evidence is missing.

Architecture fit. The release adds first-class handling for native PHP 8.1 enum types. For a Laravel package, native enum support typically reaches into persistence casting, validation, and serialization — the three seams where a package meets application code. That makes this more than a convenience feature: it changes the type contract at the package boundary. Fit with a modern Laravel estate (Laravel 10/11/12, all of which require PHP ≥8.1) is good and moves the package toward the platform baseline rather than away from it.

Integration feasibility. The change is small in surface area but wide in blast radius. Two distinct concerns are bundled into one release:

1. New capability — enums are now accepted/serialized properly. Additive, opt-in.
2. Platform floor raise — minimum PHP becomes 8.1. This is a breaking change for any consumer on PHP 8.0, and it is the part that requires a decision, not just an upgrade.

These should be evaluated separately. The second is the risk; the first is the value.

Technical risk.

• PHP 8.0 is EOL (security support ended November 2023). Raising the floor to 8.1 is defensible on security grounds and is likely aligned with the project's own supported-version policy. Risk to the ecosystem is therefore time-limited, not strategic.
• Composer will enforce the floor correctly if "php": "^8.1" is declared in composer.json. If instead the floor is raised implicitly via syntax or a transitive dependency, consumers get confusing failures rather than a clean solve error. This must be verified — it is the single highest-value check in this review.
• Serialization contract drift. If enums were previously accepted as raw strings/ints and are now coerced or emitted as enum instances, downstream JSON payloads, queue payloads, and cache entries could change shape. Backward compatibility of existing stored data is the key unknown.
• Backed vs. pure enums. Persistence layers generally require backed (string/int) enums. Whether pure enums are accepted, rejected, or silently mishandled is unspecified and is a likely source of runtime surprises.

Key questions (blocking further evaluation).

• Is the PHP ≥8.1 requirement declared in composer.json, and is that a require rather than a conflict?
• Is this release tagged as a major version? Raising a platform floor is semver-breaking for consumers on 8.0, regardless of how minor the feature is.
• Are both backed and pure enums supported? What happens on a pure enum passed to a persistence path?
• Is the wire/serialization format for enum values identical to the pre-1.1.0 string/int format? If not, is there a migration path?
• Does the package document a Laravel version constraint, and does that constraint now shift (Laravel 9 permits PHP 8.0; Laravel 10+ requires 8.1)?
• What is the actual downstream consumer count on PHP 8.0? Unknown — no usage data was provided.

Integration Approach

Stack fit. The package now sits at PHP 8.1+, which is the floor for Laravel 10 and above. Any application on Laravel 10/11/12 is already compliant, so this release is a no-op on runtime prerequisites for the majority of a modern estate. Applications still on Laravel 9 with PHP 8.0 are the only cohort that experiences this as a hard stop.

Migration path. Sequence for a consumer application:

1. Inventory PHP runtime versions across all environments — production, staging, CI runners, Docker base images, and any shared-hosting or managed-platform targets. CI and container images are the most common laggards and the most common cause of "works locally, fails in pipeline."
2. Confirm the framework version already implies PHP ≥8.1. If it does, the runtime work is likely already done and only the dependency bump remains.
3. Pin the package constraint deliberately rather than accepting a floating range: adopt ^1.1 only after step 1 passes, and hold at ^1.0 otherwise.
4. Adopt the enum capability opt-in, per call site, rather than as a sweeping refactor. The feature is additive; there is no reason to convert existing string/int usage in the same change window as the version bump.

Compatibility. Two independent constraints must both be satisfied: the PHP floor and the framework version. Pin both explicitly. Where the package is a transitive dependency of other internal packages, check for a split constraint graph — one package pinned to PHP 8.0 will block the update across the whole tree, and Composer's error message in that case points at the wrong package.

Sequencing relative to the release. Treat the two bundled changes as two adoption steps: raise the runtime floor first (infrastructure work, no code changes), then adopt enums (code work, no infrastructure changes). Doing them together conflates two failure modes and makes rollback ambiguous.

Operational Impact

Maintenance. The package's maintenance burden shifts favorably: PHP 8.1+ only means no dual-support matrix, no 8.0 compatibility shims, and a smaller CI matrix. That generally correlates with faster release cadence and fewer conditional code paths. For the consuming team, the ongoing cost is a pin constraint that must be revisited only when the next floor raise lands.

Support. Expect a short tail of upgrade friction concentrated in environments with slow-moving base images. The most likely support tickets are Composer solve failures (transitive constraint conflicts) and enum serialization surprises (payload shape changes), in that order. Neither is a package defect, but both will be attributed to the release.

Scaling. Neutral. Enum support does not change runtime performance characteristics in any material way. The PHP floor raise may improve performance for consumers who were on 8.0, since 8.1 and later carry meaningful engine-level improvements — a secondary benefit, not a reason to adopt.

Failure modes to watch.

• Silent serialization drift — highest severity, lowest detectability. Enum values serialized differently than before would break API consumers, queued jobs replayed from old payloads, and cached entries. Requires an explicit check, not an assumption.
• Implicit platform floor — if the 8.1 requirement is not declared in composer.json, consumers get a runtime fatal instead of a clean dependency error. Diagnosability problem, not a correctness problem.
• Pure enum mishandling — a pure enum reaching a persistence path could throw or be silently coerced. Low frequency, high confusion.
• Partial-fleet upgrade — mixed PHP versions across environments producing environment-specific behavior. This is an infrastructure failure mode, not a package one, but this release is the trigger that exposes it.

Ramp-up. Low for the feature itself — developers familiar with PHP 8.1 enums need no introduction, and the API surface is idiomatic. The real ramp-up cost is the one-time infrastructure audit in the Integration Approach, which is measured in days, not weeks, and is proportional to the size of the runtime fleet rather than to team size.

Recommendation pending the blocking questions above: the capability is worth adopting, but the release should be treated as a major-version, infrastructure-gated change rather than a routine minor bump. Do not adopt on a floating constraint. Verify the composer.json PHP declaration and the enum serialization format before committing, and confirm the version tag reflects the breaking nature of the floor raise.