Laravel Helpers Laravel Package

Product Decisions This Supports

• Build vs. buy (internal tooling): Confirms whether ronas-it/laravel-helpers remains a low-cost dependency for shared Laravel utilities, or whether our teams should standardize on the newly split-out EntityGenerator package for scaffolding/codegen workflows.
• Roadmap hygiene / dependency lifecycle: The 3.8.3 patch is a deprecation signal, not a feature release. It tells us the package is being decomposed, which directly affects upgrade planning for the next minor/major bump and any Laravel version upgrade tracks.
• Developer-experience investment: If our teams rely on the exception classes bundled here (e.g., standardized API/domain exceptions), deprecating them is a cue to budget migration effort into the EntityGenerator package or to internalize those exception classes in our own app/domain layer.
• Support & maintenance posture: A maintainer actively refactoring and relocating code (rather than abandoning it) is a positive maintenance signal; useful when deciding whether to keep the dependency in long-lived production services.
• Not a decision driver for: customer-facing features, pricing, or GTM. This is purely an engineering-enablement/dependency decision.

When to Consider This Package

Adopt / keep when:

• You are on a Laravel codebase that already standardizes on RonasIT conventions and you want shared entity generation + helper utilities without hand-rolling them.
• You want codegen (models, migrations, factories, resources) driven by a consistent, opinionated generator rather than ad-hoc artisan stubs.
• The dependency is used for non-critical, internal tooling where a deprecation cycle is affordable.

Look elsewhere / proceed with caution when:

• You depend on the deprecated exception classes. 3.8.3 explicitly marks them deprecated and moved to the EntityGenerator package. Without a stated removal version or timeline, treat them as at-risk: either migrate to EntityGenerator now, or vendor the exception classes into your own codebase so a future major release cannot break you.
• The package is on a critical runtime path (request handling, error mapping, API contracts) — exception relocation is a potential silent breaking change at the next major.
• You are not already in the RonasIT ecosystem; the value proposition (helper functions + generator) is weaker if your team already has established scaffolding conventions.
• You need a documented, long-term support commitment — the release notes give no deprecation window, no upgrade guide link, and no migration mapping for the moved exceptions.

Immediate action for current consumers: pin to ~3.8.0, grep for usages of the deprecated exception classes, and open a ticket to either migrate to EntityGenerator or vendor them before the next major.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a routine patch release to an internal Laravel utility library, and it carries no new customer-facing functionality. The one thing worth noting is that the maintainers are splitting the library's exception-handling code into a separate package and have begun deprecating the old classes. There is no immediate breakage and no cost today, but it starts a clock: at some future major release those classes will likely be removed. We recommend a small, bounded piece of engineering work — inventory where we use those exception classes and either migrate to the new package or copy them in-house — so a future upgrade isn't a surprise. Total exposure is low; no roadmap changes are required unless we discover deep coupling.

For engineering leads: 3.8.3 is a deprecation-only release — exception classes are marked deprecated and relocated to the EntityGenerator package. Treat it as a heads-up, not a break: no API changes ship in this patch, but the deprecation has no published removal version, so we should pin ~3.8.0, audit call sites, and schedule migration/vendoring ahead of the next major. Also flag it in our dependency-review checklist so we catch the actual removal release.

For the VP/eng manager deciding on effort: low urgency, low effort, non-zero risk if ignored. One short spike (audit + migration plan) is sufficient; defer the implementation until either the removal release lands or the affected service is next touched for other reasons.