Laravel Chronos Laravel Package

Product Decisions This Supports

• Build vs. buy for model-level behavior. v1.1.0 confirms this package is maturing from a single hard-coded integration path (extend a provided base model) to a composable one. That reduces the "we could build this in a sprint" argument, because the cheap internal version is usually a base-model subclass that becomes a maintenance liability the moment your domain needs its own inheritance chain.
• Brownfield vs. greenfield adoption. The trait option is a genuine roadmap unblocker: teams already extending Model, or already using another base class (tenant models, audited models, UUID/ULID bases), can now adopt without a class-hierarchy migration. This turns a "next new project only" decision into a "can be trialed on one existing service" decision.
• Scope of a pilot. The trait path is the natural pilot surface: enable it on one or two models in a single bounded context, measure behavior and query impact, then decide on wider rollout. The base-class path stays available for greenfield work where you control the hierarchy.
• Tech-debt sequencing. If a backlog item exists to consolidate ad-hoc model behavior (event hooks, custom casts, observers, base classes), this release makes "consolidate onto the package's trait" a viable candidate for the next hardening cycle rather than a rewrite.
• Vendor-lock and exit cost. Trait-based integration is the easier one to unwind — one use statement per model — which lowers the perceived risk of the dependency in architecture review.

When to Consider This Package

Adopt when most of the following hold:

• You have more than a handful of Eloquent models that would need the behavior, so a per-model hand-rolled implementation would be duplicated logic.
• Your models already inherit from something (a base model, tenancy, UUID keys, an audit base class) — with v1.1.0 this is no longer a blocker, and is in fact the intended use case for the trait.
• You want the behavior declared per model rather than applied globally, or you need to roll it out incrementally.
• The behavior is not central to your competitive differentiation — it's plumbing you'd rather buy and keep patched.
• You can accept a small third-party surface area in your domain layer and have someone who owns Laravel upgrades.

Look elsewhere or wait when:

• You need guaranteed long-term maintenance and the package has a single maintainer with no release cadence — treat it as a dependency with a bus factor to manage.
• The behavior is load-bearing for correctness or compliance (audit trails, financial history) and you need vendor-level support, SLAs, or a documented deprecation policy.
• Your models are already consistent — one base class you control, few models — in which case a trait from a package adds a dependency for near-zero gain.
• There's overlap with framework or first-party features already in use; running two mechanisms is worse than either alone.
• The trait and base-class paths diverge in behavior — worth verifying before committing, since dual integration paths are a classic source of subtle inconsistency.

How to Pitch It (Stakeholders)

To executives: This is a small, low-commitment library that replaces code we'd otherwise write and maintain ourselves for common model behavior. The v1.1.0 release adds an integration option that means we can adopt it without restructuring existing code, so the trial is a one-model change, not a migration project. Cost is a dependency; benefit is deleting a category of boilerplate we currently maintain in-house. Recommend a time-boxed pilot on a single bounded context, with a go/no-go on wider adoption after.

To engineering: v1.1.0 adds a trait as an alternative to extending the package's model class. This matters because it removes the inheritance constraint — we can use the trait on models that already extend our own base, and we can adopt per-model rather than globally. Before rollout we should: (1) confirm the trait path and the base-class path are behaviorally equivalent, (2) check the trait against our existing base model for method, property, and boot-hook collisions, (3) verify serialization and query behavior on a representative model, and (4) confirm the trait is compatible with our model event listeners and any global scopes. One caveat to factor in: the package is a single-maintainer dependency, so if we go wider than the pilot, we should pin versions and note the fallback (a local trait) in the ADR.