Extension Laravel Package

Getting Started

Verify installability before anything else. This package is archived, so its composer.json almost certainly pins an older illuminate/support range. Check the constraint first:

composer show laravel-plus/extension --all   # inspect requires + available versions

If your app is on a current Laravel release, expect a dependency conflict. Options, in order of preference: fork it under your own vendor namespace, install with --with-all-dependencies on a legacy branch, or skip it and copy the two or three helpers you actually need into app/Support/.

Install and look at what it registers:

composer require laravel-plus/extension

Then read, in this order:

1. composer.json — the require block, and whether it declares extra.laravel.providers (auto-discovery) or expects manual registration.
2. The service provider in src/ — this is the real API surface. Note every $this->app->bind(), Blade::directive(), macro(), and helper file require.
3. Any config/*.php — publish it so you can see every knob without reading source:

php artisan vendor:publish --provider="LaravelPlus\Extension\ExtensionServiceProvider"

First use case: do not adopt the pack as a unit. The pack is a bundle of unrelated conveniences (helpers, macros, generator commands, directives). Pick the single feature that solves your immediate problem, wire it in, and leave the rest dormant. That keeps your blast radius small when you eventually remove the package.

Implementation Patterns

Adapter-first adoption. Because the package is unmaintained, never call its helpers or macros directly from controllers, models, or Blade views. Wrap each one you use in your own class:

// app/Support/Slug.php
final class Slug
{
    public static function make(string $value): string
    {
        return \LaravelPlus\Extension\...::slugify($value); // the one call site
    }
}

When you fork or replace the package, you edit one file instead of grepping the codebase.

Audit-then-enable. Walk the provider and write a short inventory: helpers loaded, macros registered, commands registered, config keys. For each item decide adopt / ignore / reimplement. Anything you can't explain in one sentence, reimplement — a 20-line helper you own beats an unmaintained dependency.

Config pinning. Publish the config file and commit it. Never rely on package defaults for anything behavioural (prefixes, table names, feature toggles) — archived packages ship defaults tuned to a Laravel version you are not running, and a fork or replacement will silently change them.

Version pinning in CI. Never use a floating constraint on an archived package. Pin the exact version in composer.json and commit composer.lock. Treat any lockfile diff on this package as a code review trigger.

Migration-shaped integration. If the pack registers macros on Collection, Str, Request, or Blueprint, centralise them in a single service provider of your own that uses the package's trait/macro registration. That provider becomes the one place you delete from later.

Test against the behaviour, not the package. Write tests against your adapter, so a fork swap does not invalidate your suite. Do not write unit tests that assert on a package class name — you are testing a frozen artefact.

Gotchas and Tips

• No auto-discovery on older packages. If composer.json lacks extra.laravel.providers, register manually in bootstrap/providers.php (Laravel 11+) or config/app.php.
• Helper function collisions. Older extension packs define global functions like str_*, blank(), optional(), array_* that now exist in illuminate/support. A collision produces a fatal Cannot redeclare at boot, not a useful error. Guard by loading the package's helper file conditionally, or fork the file and drop the duplicates.
• Boot-order surprises. Config values read in register() are null. If something behaves oddly in production but fine in tests, dump the provider's register vs boot split with php artisan about and a temporary dump() in each.
• Silent macro shadowing. A package macro on Collection or Str will override or be overridden by a Laravel-native method of the same name depending on version. Grep the provider for macro( and compare against the framework's current method list.
• Debugging an unexplained behaviour. Run php artisan vendor:publish and diff the published config against the package's config/ — published-then-abandoned config files are the classic source of "why is this prefix wrong".
• Extension points that actually work. Binding your own implementation over the package's container keys, subclassing its service provider to skip unwanted registrations, and composer replace-ing it with your own fork. All three are safe; patching vendor/ is not.
• Security posture. Archived + 0 dependents means no one is watching for CVEs and no one will report them. Keep it off any code path that touches user input, file uploads, or auth. If it does, reimplement.
• Removal budget. Before adopting, spend 30 minutes writing down what replacing it would take. If that estimate is under a day, just do the replacement now.