Model Attributes Laravel Package

Product Decisions This Supports

• Build vs. buy on model accessor boilerplate: the package replaces hand-written getFooAttribute/setFooAttribute methods with declarative PHP attributes on Eloquent models. That is a small but real maintenance cost across a large domain model — relevant if your roadmap includes consolidating legacy models or a schema-heavy rewrite.
• Feature-level decision: standardising attribute handling: if several teams are each inventing their own accessor/cast conventions, this package is a candidate "one way to do it" standard, decided once at the architecture level rather than per-feature.
• Roadmap signalling for platform currency: v0.2.0 lands PHP 8.2 and Laravel 10 support. If your upgrade roadmap includes Laravel 10 / PHP 8.2, this package is no longer a blocker; if you are still on Laravel 9 / PHP 8.1, adoption is now gated.
• Not a differentiating capability. Nothing here changes what the product can do for customers. Treat it as an engineering-ergonomics line item, not a roadmap pillar — it does not justify its own initiative, only a slot inside an existing refactor.

When to Consider This Package

Consider it when:

• You are on PHP 8.2+ and Laravel 10 — this release is the first to support that combination, and the earlier v0.1.0 line should now be treated as superseded.
• You have a meaningful number of Eloquent models where attribute logic is scattered across accessor methods and you want it co-located and declarative.
• Your team is already comfortable with PHP 8 attributes (or with #[Cast]-style patterns) and will not need a tutorial to read a model class.
• You can absorb a v0.x dependency — pre-1.0 means the public API can still shift under you without a major-version bump.

Look elsewhere (or wait) when:

• You are on PHP 8.1 or Laravel 9 — v0.2.0 explicitly moves the floor to PHP 8.2, so this release does not help you; staying on v0.1.0 means running an unsupported branch.
• Your model layer is small or already consistent — the abstraction buys little.
• You need long-term API stability guarantees for a long-lived product; a pre-1.0 package with two releases and two first-time contributors is a supply-chain risk worth naming.
• Established alternatives (native Laravel casts/accessors, or a mature attribute package) already cover the need — migration cost likely exceeds the ergonomic gain.

Adoption criteria in one line: adopt only on PHP 8.2 / Laravel 10, scoped to a refactor you were already doing, and pin the version.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-risk developer-ergonomics library for our Laravel codebase. The new release (v0.2.0) is purely a compatibility update — it adds support for PHP 8.2 and Laravel 10 and requires no product changes. Its practical value is that it no longer blocks our planned framework upgrade; the library itself delivers no customer-facing feature, so I am not asking for roadmap time, only noting that it is safe to carry forward. The caveat is that it is pre-1.0 and single-maintainer-ish, so we should pin the version and keep a trivial fallback to plain Laravel accessors.

For engineering leads: v0.2.0 bumps the floor to PHP 8.2 and adds Laravel 10 support; there are no new features, no deprecations, and no API changes called out in the changelog. If you are on Laravel 9 / PHP 8.1, do not take this upgrade — v0.1.0 is now the older, unsupported branch and you should plan the framework bump instead. If you are on Laravel 10, the upgrade is routine. Two first-time contributors landed these PRs, which is a positive maintenance signal but not yet a track record — pin the version in composer.json and avoid spreading the attribute syntax across the whole model layer until the package reaches 1.0 or we have run it in production for a release cycle.