Laraveleasyattendance Laravel Package

Product Decisions This Supports

• Build vs buy for the HR/attendance domain. The package already models the commodity surface — Leave, AttendanceSummary, SalarySlip, Designation, EmployeeShift, plus an AttendanceController — so the buy side of the decision is about fit, not coverage. v2.3.1 doesn't change that calculus on features; it changes it on carrying cost.
• Integration strategy: bring-your-own Employee model. The attendance.subject_model runtime configuration (and the HasAttendance/HasPackageTable traits) means we keep our own Employee/User and let the package attach to it. This is the single most important architectural fact for the build-vs-buy call — no user-table migration, no dual source of truth.
• Engineering-quality gate on a dependency. The baseline going 154 → 16 entries is a concrete, checkable proxy for maintainability. For a package we'd be vendoring into a long-lived product, "the maintainer is actively shrinking static-analysis debt" is a risk signal we can act on and re-check each release.
• CI/tooling decision. If our pipeline runs Larastan at a meaningful level, this release removes most of the noise this dependency would otherwise contribute — and, critically, the fixes were real (int cast in Leave::daysCount(), explicit BelongsTo returns on AttendanceSummary::employee(), SalarySlip::employee(), Designation::department(), EmployeeShift::shift()) rather than new ignores. That distinction matters: suppressions compound, fixes don't.
• Onboarding and ramp-up cost. Full @property/@property-read docblocks across every model mean PhpStorm/Intelephense autocomplete on columns, casts, and relations inside our app. This is a direct reduction in "read the package source to learn the schema" time for every engineer who touches the HR module.
• What it does not support. No user-facing capability, no roadmap-visible feature, no breaking change. Do not let a DX release move a roadmap date or reset a prior functional evaluation — conclusions on behavior from v2.3.0 still hold.

When to Consider This Package

Consider it when:

• You're on Laravel and need attendance, leave tracking, shifts, and salary-slip domain modeling — and would otherwise spend a sprint re-deriving the schema and relations.
• You have an existing Employee/User you don't want to fork — attendance.subject_model is the designed escape hatch, and the release notes confirm it's the intended architecture, not an accident.
• Your team runs Larastan/PHPStan and cares about relation-name validation (->with('employee')) resolving correctly; typed relation returns are exactly what makes that work.
• You want IDE autocomplete on domain models without maintaining your own stub generation.

Look elsewhere when:

• You need a payroll engine. SalarySlip is a model, not statutory tax, contributions, or multi-country compliance logic.
• You need shift-scheduling optimization or labor-law rule engines. Out of scope for what's described here.
• You require a zero-baseline static-analysis gate across all dependencies. The 16 remaining findings are the deliberate polymorphic cost of attendance.subject_model, documented on AttendanceController. They are not going away. If your policy forbids per-dependency baseline exceptions, that's a permanent, principled conflict — not something a future patch will fix.
• You need sub-day or time-of-day attendance precision. The release explicitly notes diffInDays() is used on date-only casts where sub-day precision "can't occur." Fine for day-granularity leave; a mismatch if you need hours.
• You need an admin UI out of the box. Evaluate separately; nothing here indicates one.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a maintenance release for the attendance package under evaluation — no new features, no breaking changes, no migration work. Its significance is risk, not capability: the maintainer is actively tightening type safety and paying down static-analysis debt rather than suppressing it, which is the behavior you want to see in a dependency you'd carry for years. The build-vs-buy case for the attendance/leave/salary-slip domain is unchanged on features and slightly improved on long-term maintenance cost.

For engineering: v2.3.1 is a developer-experience and static-analysis release. Every model now ships complete @property/@property-read docblocks covering columns, cast types, and relations, so PhpStorm and Intelephense autocomplete work directly in consuming apps rather than requiring generated stubs. The phpstan-baseline.neon for the package dropped from 154 entries to 16, and the changelog is explicit that these are real fixes rather than new ignores: Leave::daysCount() now casts diffInDays() to int (upstream returns float for sub-day precision that cannot occur between two date-only casts, so the method's int return was already semantically correct — just not statically provable), and four relation methods gained explicit BelongsTo return types because Larastan's eager-load validation won't recognize a method as a relation without one. The 16 residual findings are all the same architectural pattern — HasAttendance/HasPackageTable methods invoked through the runtime-configured attendance.subject_model, which could be any consuming app's model and is therefore genuinely unknowable to static analysis. That's documented on AttendanceController; it is a design tradeoff, not a defect.

The one thing to flag before adopting: if we buy in, we should budget for a small, justified baseline exception around that trait surface and document why it exists, so a future engineer doesn't "fix" it by weakening the type. The payoff — autocomplete on every column and relation, and meaningful Larastan signal on our own code — is worth that one documented carve-out.