Support Laravel Package

Product Decisions This Supports

• Build vs. buy for an internal shared-utility layer. This package is the "buy" option for a very narrow problem: shared helpers, service-provider bootstrapping, and reusable Laravel integration glue across a family of related packages. If your roadmap includes shipping multiple Laravel packages (SDK, connectors, modules) that must stay consistent, laravelha/support is the reference model for how to factor that shared layer — one small package, no framework coupling beyond illuminate/*, MIT licensed.
• Not a feature-delivery dependency. Nothing here maps to customer-facing capability. There is no domain logic, no integration with a third-party API, no schema. A PM should not place it on a roadmap line item; it belongs in the engineering-platform backlog, if anywhere.
• Informs a "do we need our own kit?" decision. The package's real product value is as a pattern precedent: it demonstrates the shape of a house-style support package (helpers + provider bootstrap + reusable patterns). If your team has three or more packages duplicating helper code, this is a template to copy, not a dependency to install.
• Ecosystem-hedging signal. The LaravelHA ecosystem is small and this package's last release was October 2020 with zero public dependents. That is a data point for any decision that depends on third-party Laravel packages: adoption breadth is a leading indicator of whether a package will still be maintained when you need to upgrade Laravel. Use it as a worked example when setting your own adoption bar.
• Upgrade-surface budgeting. Adopting any utility package adds a recurring step to every Laravel major upgrade. This package, being 2020-vintage and pre-2.x, would add that step with essentially no offsetting benefit — a useful anchor when negotiating how many small dependencies your team is allowed to accumulate.

When to Consider This Package

Consider it only if all of the following hold:

• You are building or maintaining packages inside the LaravelHA ecosystem and need to match its conventions or satisfy an existing transitive requirement.
• You have verified via composer.json that its illuminate/* constraints cover your current and planned Laravel/PHP versions — a 2020-era constraint set almost certainly stops before Laravel 9/10/11, and an unbounded constraint is worse than a tight one.
• You have read the source directly. There is no changelog, no meaningful documentation beyond a one-paragraph description, and zero public dependents to infer behaviour from.
• The utility surface you need is genuinely trivial (string/array helpers, a provider base class) and you have accepted that you may end up forking it — the cost of maintaining a fork should be cheaper than the code you would otherwise write.

Look elsewhere — or write the twenty lines yourself — if any of these are true:

• You need maintained code. Last release 2020-10-07, 8 stars, 0 dependents, single-ecosystem scope. There is no maintenance signal to rely on.
• You need upgrade safety. No changelog on the last release means every bump is a diff review; that is a tax you should not pay for helper functions.
• You need support or an escalation path. There is none documented, and no evidence of paid support or organisational backing.
• Your team is not already in the LaravelHA ecosystem. There is no interoperability reason to take the dependency, and every reason (security review, licence review, upgrade surface, composer.lock churn) not to.
• You are evaluating this as a solution to a product problem. It solves an internal packaging-consistency problem belonging to another team.

Net PM recommendation: treat as reference material, not a dependency. Copy the pattern if you need a house-style support package; do not put it on the critical path.

How to Pitch It (Stakeholders)

For executives (60 seconds): A small, MIT-licensed Laravel utility package from a community ecosystem. Eight GitHub stars, zero downstream dependents, last released in October 2020. It is not a product dependency and I am not recommending adoption. The reason it is worth thirty seconds of your attention is that it is a clean example of a decision we do face repeatedly: whether to accumulate small third-party packages that each add a line to every future framework upgrade. My recommendation is to use it as a template if and when we build our own shared internal utilities, and otherwise leave it alone. Cost of adopting: near-zero licence cost, non-trivial maintenance drag. Cost of skipping: zero.

For engineering leads: This is a shared-support package for the LaravelHA package family — helpers, provider bootstrapping, reusable integration patterns. It is not a library with an API you will build against; it is plumbing. Two things make it unusable as a dependency today: the illuminate/* constraints were last touched in 2020 and will not span current Laravel majors, and there is no changelog, so every patch bump would be a manual diff. What is worth taking is the structure — if we are shipping multiple internal packages, this is a reasonable shape for the shared layer we should own ourselves: helpers isolated, provider bootstrap standardised, no framework-adjacent reimplementation. Concretely: don't add it to composer.json. If you are touching duplicated helper code across two or more of our packages, open a ticket to consolidate it internally and use this repo as a reference for layout. If anyone does want to trial it, the bar is: pin to an exact version, verify the framework version matrix in a scratch branch, run the full suite before any call site uses it, bind behind our own interface so removal is one file, and record the decision — including that it was adopted with no changelog — in the PR description.

One-line summary for the decision log: Evaluated laravelha/support (v1.0.4, Oct 2020, 8 stars, 0 dependents) as a shared-utility dependency. Rejected for adoption on maintenance and framework-compatibility grounds; retained as a structural reference for an internal shared package. No roadmap impact.