Helpers Bundle Laravel Package

Product Decisions This Supports

This release (v2.0) is an architectural change, not a feature release: every helper that was previously exposed as a static method is now an injectable service. That single decision changes what the package is good for, and it drives several PM-level calls.

• Build vs. buy for shared utilities. Removing statics is the clearest signal that the maintainers are optimizing for long-lived application code rather than quick scripts. If our roadmap includes multiple Laravel services that need the same helper behavior, adopting this now avoids us writing and maintaining an in-house utility package later.
• Upgrade sequencing on the roadmap. v2.0 is a breaking change. Any code path that calls these helpers statically will fail after upgrade. This needs a scheduled slot in an upcoming sprint with a defined migration window — it is not a "bump the constraint and see what breaks" change.
• Architecture standard: DI-first. If we are pushing teams toward constructor injection, container bindings, and mockable collaborators, this release brings the package in line with that standard. It is a supporting data point for codifying "no static helper calls in application code" as a team convention.
• Test strategy investment. Injectable services can be swapped for test doubles; static calls cannot be intercepted cleanly. This release lowers the cost of unit-testing code that depends on these helpers, which materially affects our test-coverage targets and the effort estimate attached to them.
• Technical debt reduction and deprecation risk. Statics are a common source of hidden coupling. Choosing the v2.0 line means we stop accruing that debt; staying on v1 means we own a fork of behavior the maintainers are actively moving away from.
• Use-case fit. The package is now better suited to application and domain-layer code where dependencies are managed by the container, and less suited to throwaway scripts, config files, or migration/seed contexts where injection is awkward. That distinction should shape where we recommend it internally.

When to Consider This Package

Adopt when most of the following hold:

• The project is greenfield or already DI-oriented — controllers, jobs, and services resolve dependencies through the container, so injecting a helper service is a one-line constructor change.
• Testability is a stated requirement. If the team needs to mock or fake helper behavior in tests, service-based helpers are a direct win over statics.
• Framework and PHP version constraints are satisfied by v2.0's requirements, and the package is still actively maintained.
• Multiple consumers exist or are planned, making a maintained dependency cheaper than an internal utility module.
• The team can absorb a one-time refactor of static call sites, or has no call sites at all.

Look elsewhere or defer when:

• The codebase is saturated with static calls to these helpers and has thin test coverage — the migration is a refactor project disguised as a version bump, and the payoff may not justify it this quarter.
• You need one or two small functions. Writing them locally is cheaper than adding a dependency, a breaking-change surface, and an upgrade obligation.
• The usage sits in contexts hostile to injection — config files, service providers bootstrapping early, Artisan commands that must run before the container is fully wired, or Blade templates expecting global helpers.
• Maintenance signals are weak. A major version that removes statics implies follow-through; confirm there is a release cadence and an issue tracker that responds before committing.
• You are on a v1 pin with a hard delivery date. Ship first, migrate deliberately — do not fold a breaking dependency upgrade into a release that is already at risk.

How to Pitch It (Stakeholders)

To executives: This is a housekeeping upgrade with a real payoff and a real cost. The package's v2.0 release converts its helpers from global static functions into injectable services, which is the standard pattern for testable, loosely coupled Laravel code. The benefit is lower long-term maintenance cost and better automated test coverage on code that uses these helpers. The cost is a bounded refactor of existing call sites plus a regression-test pass. Recommend scheduling it as a discrete piece of work rather than attaching it to a feature release.

To engineering: v2.0 removes all static methods from the helpers; each helper is now a service resolved through the container and injected via constructor. Anything calling Helper::method() must be rewritten to inject the service. The upside is that helper behavior becomes swappable in tests — no more fighting statics to assert a failure path. Plan the work as: inventory static call sites, add container bindings if we need custom implementations, refactor call sites, then verify with the existing suite plus new tests around the previously unmockable paths. Flag any usage in config, providers, or views early — those are the awkward cases and may warrant a thin local wrapper.