Parkour Laravel Package

Technical Evaluation

Architecture fit. fg/parkour is a framework-agnostic leaf utility library — a bag of static array helpers (dot-path get/set, flatten, pluck-style accessors, recursive transforms). Architecturally it is the easiest possible dependency to absorb: no service provider, no config, no I/O, no state. The problem is not fit, it is overlap. Laravel has shipped Illuminate\Support\Arr since 5.0 with a superset of the typical operations this package provides (get, set, has, forget, pluck, flatten, dot, undot, wrap, first, last, where, accessible). Unless the package exposes a specific recursive-merge or deep-transform primitive that Arr handles awkwardly, we would be adding a dependency to duplicate first-party code.

Integration feasibility. Mechanically trivial, practically awkward. The package is a 2015-era Composer library: expect no return types, no scalar type hints, PHP >=5.4-style constraints, and no Laravel package discovery (irrelevant here, since there is nothing to discover). It will likely install on PHP 8.x only with --ignore-platform-reqs or a version-constraint override in composer.json, and may emit deprecation notices on 8.1+ for null-to-non-nullable coercion. That is survivable — but "survivable with flags" is a smell for a utility we do not need.

Technical risk.

• License (NOASSERTION) — the highest-severity item. We cannot ship code into a commercial product without a human reading the LICENSE file and confirming terms. GitHub failing to classify it usually means a custom or ambiguous grant. This alone blocks adoption pending legal review.
• Abandonment — last release 2015-10-03, roughly a decade of drift against PHP 7/8 semantics, no upstream to patch bugs or add PHP version support.
• Zero dependents, 14 stars — no battle-testing signal, no ecosystem feedback loop, no Stack Overflow corpus. We become the de facto maintainer.
• Supply-chain — pinning to a single 2015 tag of a low-visibility repo is a weak link; if the tag or repo disappears, builds break.
• Behavioral drift — hand-rolled dot-path helpers frequently diverge from Arr on null handling, empty-string keys, and numeric-key coercion. Silent divergence is the realistic failure, not an exception.

Key questions.

1. What specific function(s) do we need that Illuminate\Support\Arr or data_get()/data_set() do not already provide? Get a concrete list — I expect it to be small.
2. Is this a deliberate dependency, or a transitive artifact left over from a legacy install? (Dependents: 0 suggests nobody chose it recently.)
3. What does the LICENSE file actually say? Until answered, assume no redistribution rights.
4. Which PHP and Laravel versions must be supported at the point of consumption? If 8.1+, budget for a fork.
5. How many call sites exist today, and are they covered by tests? That determines whether replacement is a one-day or one-sprint task.

Recommendation: do not adopt as a new dependency. If already present, treat it as technical debt to be retired, not a library to be maintained.

Integration Approach

Stack fit. Poor-to-neutral on modern Laravel. On Laravel 9–11 the idiomatic choice is Arr:: / data_get() / Collection, all of which are documented, tested, and PHP-8-native. On a legacy 5.x/6.x codebase the same argument holds — Arr has existed throughout. The only defensible fit is a non-Laravel PHP service where we want these helpers without pulling in illuminate/support; even then, a 200-line internal helper file is cheaper than a decade-stale dependency.

Migration path (if already in the tree).

1. Inventory — grep every call site and classify each helper as (a) direct Arr equivalent, (b) trivial to reimplement, (c) genuinely unique.
2. Pin and isolate — before touching call sites, freeze to the exact current tag and wrap usage behind a single App\Support\Arrays adapter so there is exactly one import to change later.
3. Differential test — write characterization tests against current behavior for the (c) group, including null/empty/numeric-key edge cases. This is the step teams skip and regret.
4. Replace — swap (a) to Arr, port (b) into App\Support\Arrays, and port (c) with the characterization tests as the spec.
5. Remove — drop the Composer requirement once the adapter has no remaining Parkour imports; lockfile diff is the completion proof.

Compatibility. Verify composer.json PHP constraint against our matrix before anything else; if it blocks, prefer vendoring the source into app/Support under our license header subject to the real license terms. Watch for global-function declarations — those can collide with other legacy helpers and produce fatal redeclare errors during autoload, which is a nasty failure to debug in production.

Sequencing. Do the license review and call-site inventory in parallel and first — both are cheap and either one can kill the initiative. Only then decide between replace (preferred) and fork (acceptable if the unique surface is real). Never sequence this alongside a framework upgrade; you want a clean before/after signal.

Operational Impact

Maintenance. Effectively zero upstream. Once adopted, we own bug triage, PHP-version compatibility, and security posture. The code surface is small enough that a fork is genuinely maintainable — but it lands on our roadmap, and "we forked a 2015 array helper" is a story that recurs every PHP upgrade cycle. Replacement eliminates that recurring tax entirely.

Support. None available. No issue triage, no maintainer response, no security advisories. For a pure-function library with no I/O, no deserialization, and no network surface, the security blast radius is near-zero — the risk is correctness drift, not exploitation. Frame it that way to stakeholders: this is a maintainability decision, not a vulnerability decision.

Scaling. Performance is a non-issue at request scale; these are pure functions over in-memory arrays. The one caveat is deep recursive operations on large payloads — naive implementations copy arrays per level and can blow memory on multi-MB nested structures. If any call site runs on a hot path over large collections, benchmark against Arr:: equivalents before committing.

Failure modes.

• Silent behavioral divergence from Arr semantics — wrong null handling, dot-paths containing literal dots in keys, numeric string keys cast unexpectedly. Highest likelihood, highest detection cost.
• Fatal redeclare on autoload if the package or our copy defines global functions that clash with legacy helpers.
• Deprecation noise on PHP 8.1+ from null-to-non-nullable argument passing — harmless individually, corrosive to log signal-to-noise and can trip strict CI error handlers.
• Build fragility if the 2015 tag or repo is ever removed from Packagist/GitHub; mitigate by vendoring source and committing it with attribution.
• License exposure discovered late — i.e., after the code is in a shipped artifact.

Ramp-up. Very low. A mid-level engineer can read the entire source in under an hour and reimplement the used subset in a day. That low ramp-up cost is precisely the argument against adoption: the replacement cost is below the cost of governing the dependency. Total effort to retire: one to three engineer-days including characterization tests, gated on legal clearing the license if any code is copied rather than rewritten.