Support Laravel Package

Getting Started

Start by inspecting the package before installing it — at 15 stars and a last release in February 2015, prologue/support is explicitly marked [ABANDONED] in its own description, so your first task is deciding whether you need it at all or just the two or three helpers it provides.

1. Read the source first. composer show -a prologue/support and open vendor/prologue/support/src/. The package is a thin extension of illuminate/support, so almost everything you care about lives in a handful of classes plus a service provider. Check composer.json for its illuminate/support constraint — it will be pinned to Laravel 4.x/5.0-era versions and will conflict with anything modern.
2. Install into a legacy app only. If you are on Laravel 4.2/5.0, composer require prologue/support and register Prologue\Support\ServiceProvider in app/config/app.php (Laravel 4) or config/app.php (Laravel 5). If you are on Laravel 8+, skip the install and copy the classes you need into app/Support/.
3. Verify what actually registers. Run php artisan tinker and check whether the provider binds anything into the container or merely adds class aliases/helper files via files autoloading. Many 2015-era "support" packages are just a namespace of static helpers with no meaningful container wiring.
4. First use case: treat it as a source of extra collection/string/array helpers. Before adopting it wholesale, identify the specific method you want (e.g. a Collection extension or a Str-style helper), confirm it doesn't already exist in your Laravel version, and only then choose between the package, a macro, or a copy-paste.

The realistic first step for most teams today is: don't install it — vendor the one class you need under your own namespace.

Implementation Patterns

Fork-and-vendor (recommended). Because the license is MIT, the cleanest day-to-day pattern is to fork the repo, keep only the classes you use, and pull it in via a VCS or path repository:

"repositories": [
  { "type": "path", "url": "../packages/prologue-support" }
],
"require": { "acme/prologue-support": "*" }

This lets you add PHP 8 type declarations and drop the stale illuminate/support constraint without fighting Composer.

Selective adoption. Don't register the service provider if you only need one class. Import the class directly and call it statically; this avoids the provider bootstrapping anything unexpected and keeps your config/app.php clean.

Collection extension pattern. If the package subclasses or augments Illuminate\Support\Collection, prefer Laravel's native Collection::macro() in a dedicated service provider instead. It gives you the same ergonomics, is autoloaded by the framework, and is testable:

Collection::macro('pluckFirst', function () {
    return $this->map(fn ($items) => collect($items)->first());
});

Reserve the package's own collection class for places where you genuinely need a distinct type (e.g. return-type hints in a legacy module).

Standalone usage outside Laravel. Since it only depends on illuminate/support, it can be used in plain PHP projects. In that case include Composer's autoloader and instantiate the support classes directly — no service provider needed.

Testing integration. If you keep the provider, add an Orchestra Testbench test case that boots it and asserts the bindings/aliases you rely on. This is your safety net when you later patch the fork for a newer PHP version.

Gradual migration. Wrap calls to the package behind your own helper or facade (App\Support\Legacy) so that replacing it later is a one-file change rather than a grep across the codebase.

Gotchas and Tips

• Abandoned and unmaintained. Last release 2015-02-07 means no PHP 7.2+ fixes, no PHP 8 support, and use of removed functions like each(), create_function(), or old Str APIs is likely. Expect fatal errors on modern PHP until you patch the fork.
• Composer constraint hell. The illuminate/support requirement will almost certainly conflict with Laravel 6+. Don't try to force it with --ignore-platform-reqs or replace tricks in a production app — vendor the code instead.
• Name collisions. Classes under Prologue\Support\* may shadow or be confused with Illuminate\Support\* in imports and IDE auto-completion. Alias explicitly (use Prologue\Support\Str as LegacyStr;) to avoid debugging the wrong class.
• Service provider side effects. Verify whether the provider registers aliases, pushes config, or calls class_alias. Silent aliasing is a common source of "why is my Str behaving differently" bugs in legacy apps.
• Autoloading helper files. If the package lists files in its composer.json autoload, its functions are loaded globally on every request. After removing the package, run composer dump-autoload and clear bootstrap/cache or you'll chase phantom function-exists errors.
• Deferred vs. eager bindings. Old providers often bind in register() but assume boot() order relative to other packages. If a binding is missing, check php artisan tinker for app()->bound(...) before assuming the package is broken.
• Debugging checklist: composer why prologue/support (who pulls it in), composer show prologue/support (installed version vs. constraint), and php -l across src/ after any PHP upgrade.
• Extension points are limited. There is no macro system, no config file, and no events in a 2015 support package. Your extension options are: subclass the class, copy the method into your own helper, or replace the container binding with your own implementation.
• Security and supply chain. No updates since 2015 means no CVE fixes. Even for a helper library, pin an exact commit hash in your fork and review the diff before merging.
• Migration tip: grep for the package's namespace, replace each call site with an equivalent native Laravel construct (collection macros, Str:: methods, Arr:: helpers), then remove the dependency. Most of what a support extension offered in 2015 now ships in the framework.