Parkour Laravel Package

Product Decisions This Supports

• Build vs. buy on commodity utilities. Parkour is a pre-PHP-7 utility belt for array manipulation — path-based get/set/has/remove, flatten, recursive merge, grouping/plucking, and key remapping. The useful decision it informs is not "adopt this library" but "do we vendor 60 lines or pull a dependency?" For most teams the answer is vendor: these are the cheapest functions in the codebase to own and the most expensive to inherit risk on.
• Configuration and payload traversal in internal tooling. The strongest realistic use case is dot-path access into nested arrays — config resolution, request/response payload shaping, feature-flag lookups, form-data normalization. If your admin panels, importers, or API glue repeatedly do $a['x']['y']['z'] ?? null chains, that's a real readability win.
• Data transformation at the edges, never in the domain core. Grouping and flattening row-sets from CSV imports, third-party APIs, or spreadsheet exports. Keep it out of anything a customer's money or identity flows through.
• Roadmap signal, not a roadmap item. With a last release in 2015, zero dependents, and an unresolved license, this is a reference implementation to read for API design, not a component to schedule. Treat it as a source of ideas for an internal Arr helper — nothing more.
• Not a platform or standards decision. Nothing here should reach an architecture review, a vendor register, or a procurement cycle. If it does, the decision has already been over-escalated.

When to Consider This Package

Consider it only when all of the following hold:

• You are on a legacy PHP 5.x/7.0-era codebase that already lacks modern array ergonomics, and you need path-based access today with a familiar API.
• You have legal sign-off on the NOASSERTION license. This is the hard gate. An undeclared license means you cannot confidently redistribute it, ship it in a commercial artifact, or represent it in an SBOM. If legal cannot clear it in a day, stop.
• The scope is non-critical, internal, and replaceable in an afternoon — a read-only helper, not a dependency of anything with an SLA.
• You have vendored or forked it, pinned to a commit, with the code in your own repository. Ten-year-old packages without CI do not get to be live dependencies.
• You've confirmed the specific function you need isn't already covered.

Look elsewhere — or write it yourself — when:

• You're on PHP 8.1+. array_column on objects, first-class callable syntax, spread with string keys, array_is_list, and match have absorbed most of what this library existed to paper over. A 30-line Arr class with get/set/has covers the remainder with full static analysis.
• You need type declarations, static analysis, or PHPStan/Psalm level 6+. This codebase predates all of it; every call site becomes an mixed.
• You need maintenance guarantees — security response, PHP-version support, semver discipline. None exist. Fourteen stars and zero dependents means zero downstream bug surface, which is not the same as zero risk.
• You're evaluating competing options. illuminate/support's Arr (if Laravel is already present), symfony/property-access, or nikic/php-parser-adjacent tooling all carry active maintainers. In a Laravel codebase specifically, Arr::get, Arr::set, Arr::pluck, and data_get() are already in the framework you pay for.
• Anything user-facing, financial, or security-adjacent. Ever.

The honest default: do not adopt. Read it, borrow the API shape, write 40 lines, own it forever.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source PHP utility library for array handling. It solves a real but narrow problem — clean access to nested data — and it does so with a pleasant, readable API. However, it was last released in 2015, has no downstream users, no security process, and an unclear license that our legal team cannot sign off on without investigation. My recommendation is not to adopt it as a dependency. Instead, we should take the API pattern as inspiration and implement a small internal helper — roughly a day of engineering — that we fully control, can type-check, and will never create a license or audit surprise. Cost of building: negligible. Cost of an unmaintained, unlicensed dependency surfacing during diligence or an incident: not negligible. Net: we get the ergonomic benefit with none of the tail risk.

To engineering: This is fg/parkour — path-based array access plus flatten/merge/group helpers, circa PHP 5.3. Good news: the ideas are sound and the surface area is tiny. Bad news: no type hints, no CI, no releases since 2015, NOASSERTION license, zero dependents. We are not taking it as a Composer dependency. Action: implement an App\Support\Arr with get, set, has, forget, and groupBy, using dot-path semantics and mixed returns behind a strict return-type wrapper so PHPStan stays green. If you're in a Laravel module, just use data_get() and Arr:: from illuminate/support — it's already installed and maintained. If anyone believes there's a function in Parkour we genuinely can't replace in under 50 lines, bring it to me and we'll look at that one function specifically.