- What is fg/parkour used for?
- fg/parkour is a small, framework-agnostic utility library that provides static helpers for manipulating arrays: dot-path get and set accessors, flatten, pluck-style lookups, and recursive transforms. It has no service provider, no configuration, no I/O and no internal state, so it is essentially a bag of pure functions you call directly. In a Laravel application its role overlaps heavily with the first-party Illuminate\Support\Arr class and the data_get() and data_set() helpers.
- How do I install fg/parkour with Composer?
- Install it with composer require fg/parkour and call the static helper methods from your classes; there is nothing to register. Because the package ships no Laravel service provider or facade, package discovery plays no role in the install. Be aware that its composer.json carries a PHP >=5.4-era constraint, so on modern PHP runtimes you may need --ignore-platform-reqs or a version-constraint override before the install succeeds.
- Is fg/parkour compatible with Laravel 10 or 11 and PHP 8.1+?
- The package is framework-agnostic, so it will not conflict with Laravel's container or bootstrapping on Laravel 9, 10 or 11. The real compatibility question is PHP: it is a 2015-era library with no return types or scalar type hints, so it typically installs on PHP 8.x only with a platform requirement override and may emit deprecation notices on 8.1+ for null-to-non-nullable coercion. Treat it as survivable with flags rather than natively supported.
- Does fg/parkour register a Laravel service provider or publish a config file?
- No. fg/parkour is a leaf utility library with no service provider, no facade, no config file and no publishable assets, so there is nothing for Laravel's package discovery to find. You simply import the static helper class where you need it. This makes integration mechanically trivial, but it also means there is no Laravel-specific surface area that would justify the dependency.
- How is fg/parkour different from Illuminate\Support\Arr or data_get()?
- For most operations there is no meaningful difference: Laravel's Arr has shipped since 5.0 with a superset of the typical helpers, including get, set, has, forget, pluck, flatten, dot, undot, wrap, first, last and where, plus the global data_get() and data_set() functions. The only defensible reason to add fg/parkour is a specific recursive merge or deep-transform primitive that Arr handles awkwardly at your call sites. Without a concrete list of those functions, adopting it duplicates first-party, tested, PHP-8-native code.
- Is fg/parkour still maintained?
- No. Its last release was on 2015-10-03, roughly a decade of PHP 7 and PHP 8 semantic drift ago, and there is no active upstream to patch bugs or widen version constraints. The repository shows zero dependents and around 14 stars, which means no battle-testing signal, no ecosystem feedback loop and effectively no community knowledge base. If you adopt it, you become the de facto maintainer.
- What license does fg/parkour use, and can I use it commercially?
- GitHub reports the license as NOASSERTION, which usually means a custom or ambiguous grant that its classifier cannot identify. That is a blocking item for any commercial or redistributed product until a human reads the LICENSE file and confirms the terms. Until legal review is complete, assume no redistribution rights and do not ship the code.
- Is fg/parkour safe to use in production?
- There are four compounding risks: an unclassified license, a decade without maintenance, a supply chain pinned to a single 2015 tag of a low-visibility repository, and behavioral drift from Laravel's Arr on edge cases such as null handling, empty-string keys and numeric-key coercion. The realistic failure mode is silent divergence in results rather than a loud exception, which is the hardest kind of bug to catch in review. For a utility that duplicates first-party code, that risk profile is not worth it.
- How do I remove fg/parkour from an existing codebase?
- Start with an inventory: grep every call site and classify each helper as a direct Arr equivalent, trivial to reimplement, or genuinely unique. Freeze the package to its exact current tag and route all usage through a single adapter class such as App\Support\Arrays, so there is only one import to change later. Write characterization tests for the unique group that cover null, empty-string and numeric-key edge cases, then swap the adapter internals to Arr, data_get() and data_set() and confirm the tests still pass. In most codebases this is a one-day to one-sprint task depending on call-site count and existing test coverage.
- Can fg/parkour be used outside Laravel in a plain PHP project?
- Yes. It is a framework-agnostic leaf library with no illuminate/support dependency, so it can be dropped into any Composer-based PHP service that wants these array helpers without pulling in the full Laravel support package. That said, on PHP 8.1+ the same version-constraint and deprecation concerns apply. For a handful of helpers, a small internal utility file is usually cheaper and safer than a decade-stale third-party dependency.