Support Laravel Package

Technical Evaluation

Architecture fit. maxfactor/support is a horizontal helper/utility package, not a domain component. Its architectural role is to inject global functions, collection macros, or service-provider registrations that the rest of the app can call anywhere. That is the lowest-leverage integration point in a Laravel codebase: it increases coupling to the framework's global namespace while providing no bounded context, no contract, and no testable seam. It also overlaps heavily with illuminate/support (Laravel already ships Str, Arr, Collection, Number, data_get, etc.) and with the app/Support or app/helpers.php convention most Laravel teams already have. Net: near-zero architectural upside, non-trivial namespace surface area.

Integration feasibility. Trivially easy to attempt (composer require maxfactor/support), which is the trap. The real gate is version resolution. With a last release of 2020-03-31, the composer.json almost certainly pins illuminate/support at ^5.5–^7.0 and PHP at ^7.x. On Laravel 9/10/11 with PHP 8.2+, resolution will likely fail outright; forcing it with --ignore-platform-reqs buys an install but not correctness. Package auto-discovery means the service provider boots on every request in every environment, so any boot-time side effect (macro registration, config merge, Blade directive) is a global blast radius.

Technical risk. High for its size, driven by abandonment rather than complexity:

• Bus factor 1. Single maintainer, no commits in ~5 years, no security response capability.
• No community validation. 3 stars and 0 dependents means effectively zero field-testing; bugs surface in your production, not someone else's. The 0.265 score / 1.34 opportunity signal is consistent with "no organic pull" — nobody is asking for this.
• Global function collision. Helper packages typically declare bare functions guarded (or not) by function_exists. Unguarded declarations collide with other packages; guarded ones silently no-op, producing environment-dependent behavior.
• Upgrade lock-in. A pinned transitive dependency on illuminate/support is the classic cause of a blocked Laravel major upgrade.

Key questions for engineering.

1. Which specific helpers does our code actually use? (Expect the answer to be 3–8 functions out of a much larger surface.)
2. Does each of those have a native Laravel equivalent as of our target version?
3. Does it declare global functions, and are they function_exists-guarded?
4. Does the repo ship tests, and do they pass on our PHP version?
5. What are the exact illuminate/* and php constraints?
6. Is there a security/composer-audit exposure, and who owns it if we adopt?

Integration Approach

Stack fit. Only a clean fit if we are on a legacy Laravel (≤7 / PHP ≤7.4) estate where the package was authored for that runtime. On a modern stack, treat it as a code sample to mine, not a dependency to install. The package's value is its implementation, not its distribution.

Migration path. Recommended sequence is "extract, don't depend":

1. Inventory — enumerate every helper, macro, and directive the package registers.
2. Map — pair each with the native equivalent (Str::, Arr::, Collection::macro, Number::, once()); most will be redundant.
3. Vendor the residue — move the genuinely useful functions into app/Support/ as namespaced static methods or a single guarded helpers.php, with unit tests pinning current behavior.
4. Remove the dependency — the goal state is zero runtime coupling and no transitive illuminate constraint.

Compatibility. Validate against a matrix of {our Laravel version} × {PHP version}: run composer why-not, inspect extra.laravel.providers/aliases for auto-discovery, and check for published config or migrations (a helper package with migrations is a red flag). Verify any Carbon or Str internals it reaches into — those are the APIs most likely to have changed post-2020.

Sequencing.

• Week 1: timeboxed spike (1–2 days) — clone, run its tests, diff its helper list against our needs. Kill or continue.
• Week 1–2: parity tests around each helper we intend to keep, including edge cases (null, unicode, empty collections).
• Week 2: land vendored code behind the existing call sites (same signatures) so it's a no-op refactor; delete the composer requirement in the same PR.
• Week 3: full regression + one canary service if the helpers touch request/response paths.

If a hard dependency is unavoidable, pin an exact version, add a composer.json conflict guard, and register it in the dependency register with a named owner and a removal ticket.

Operational Impact

Maintenance. Adopting this means we own it. There is no upstream to send a patch to, and no maintainer to answer a "does this work on PHP 8.4" question. Budget ~2–5 engineer-days for the initial fork-and-test effort and a recurring tax at every framework upgrade; that recurring tax is the dominant cost, not the initial install.

Support. No vendor, no SLA, no release cadence. It will be flagged by composer audit / abandoned-package checks, which creates friction with security review and blocks compliance-gated releases. Internal support burden falls on whoever last touched it — i.e., whoever is unluckiest during an upgrade.

Scaling. Runtime cost is negligible: helpers are stateless pure functions, and one service provider boot is noise. The scaling risk is organizational — every service that adopts it inherits the same upgrade ceiling, so the constraint multiplies across the fleet. In a monolith it is a single annoyance; in a 20-service estate it is 20 blocked upgrades.

Failure modes (ranked by likelihood × impact):

1. Upgrade deadlock — transitive illuminate/support pin blocks a Laravel major bump. Most likely, highest total cost.
2. Fatal at boot — Call to undefined function or unguarded redeclaration after a PHP/Laravel upgrade, taking down every request rather than one code path.
3. Silent behavior drift — a helper whose semantics diverge subtly from the native function it shadows (string truncation, date math, null handling); tests pass, output is wrong.
4. Name collision — another package declares the same global function first; behavior becomes install-order-dependent.
5. Unpatched vulnerability — no upstream means no advisory and no fix; discovery happens via incident, not via tooling.

Ramp-up. Individual helpers are self-explanatory, so developer ramp-up is near zero. The real onboarding cost is institutional: new engineers must learn that foo() is a local fork with no docs, no upstream reference, and no changelog. Mitigate with a short app/Support/README.md documenting each extracted helper's origin, semantics, and rationale — otherwise it gets reimplemented, then duplicated.

TPM recommendation. Do not adopt as a runtime dependency. Run a one-week extraction spike, vendor the handful of functions that survive the native-equivalence check, and close out the package entirely. If a team insists on installing it, require an exact version pin, a named owner, and a dated removal ticket before merge.