Minions Laravel Package

Getting Started

• Confirm your app meets the new floor: Laravel 8.x or newer (added in v2.6.2). The package's composer.json illuminate/* constraint now allows ^8.0; if you were pinned below it, composer update will pull v2.6.2 in automatically under normal caret constraints (^2.6).
• Install with composer require and, if the package ships one, publish its assets: php artisan vendor:publish --provider="...\ServiceProvider" (check config/ for the generated file first — many Laravel packages register config with mergeConfigFrom and only need publishing when you actually override defaults).
• Read in this order: README.md → the package's composer.json (tells you the Laravel/PHP constraints and required extensions) → config/<package>.php (the real surface area of knobs) → src/ServiceProvider.php (shows what gets bound, aliased, and tagged).
• First use case: take the package's simplest documented entry point — usually a facade call or an injected contract — and run it from php artisan tinker before wiring it into a controller. If you can't get a one-liner working in tinker, the problem is configuration, not your application code.
• Register the service provider only if the package isn't auto-discovered (check extra.laravel.providers in its composer.json). Laravel 8 still auto-discovers, so manual registration in config/app.php usually means you're following stale docs.

Implementation Patterns

• Resolve through the container, not new. Type-hint the package's contract/manager in constructors or method signatures so Laravel injects the configured instance. Instantiating directly bypasses config and any singleton binding the provider registered.
• Facades for terse call sites, injection in services. Facades are fine in controllers and Blade; in longer-lived classes prefer constructor injection so the dependency is explicit and mockable in tests.
• Config over code. Package behaviour is generally driven by the config file. Override via config/<package>.php in your app (published) or env()-backed keys, rather than subclassing internals. If you must change behaviour, look for a documented extension point (custom driver, resolver closure, or bound interface swap) before touching vendor/.
• Driver/manager pattern. Many Laravel packages expose a Manager with extend() for custom drivers. Use Package::extend('custom', fn ($app) => new CustomDriver(...)) in a dedicated service provider rather than editing config to point at a class string, so you keep type safety and IDE support.
• Queue and events. If the package dispatches jobs or events, check whether they implement ShouldQueue and whether the connection/queue is configurable. In multi-tenant or multi-connection apps, set the connection explicitly per-tenant rather than relying on the global default.
• Testing. Bind a fake in the container or use the package's provided fake in setUp(). For Laravel 8, Http::fake(), Queue::fake(), and Event::fake() are the usual levers if the package wraps those concerns; assert on the package's public contract rather than on internals.
• Upgrade hygiene. This release is a compatibility widening, not a feature release. Pin with ^2.6.2 and let CI prove the matrix (your app's Laravel version × PHP version) rather than hand-testing.

Gotchas and Tips

• v2.6.2 is a constraint change, not a behaviour change. Treat it as a no-op at runtime. The only thing that can bite you is a transitive dependency resolution shift on composer update, so run it in CI before local, and diff composer.lock to see what else moved.
• Laravel 8 is now the floor going forward. If you're still on 6.x/7.x, this release won't install for you and you'll be stranded on the previous 2.6.x patch. Plan the framework upgrade — Laravel 8's shift to laravel/legacy-factories, string-based model factories, and the Str/Arr changes are the usual blockers.
• composer why-not is your first debugging step when the update refuses: composer why-not vendor/package 2.6.2 names the exact package pinning an incompatible constraint.
• Config cache masks edits. After changing the published config, run php artisan config:clear (or config:cache in deploy). A stale bootstrap/cache/config.php is the single most common "my config change did nothing" cause.
• Watch for silent fallbacks. Packages commonly catch exceptions and return a default/null rather than throwing. Wrap early adoption in explicit assertions or check the package's log channel before assuming a call succeeded.
• Don't edit vendor/. If the package lacks an extension point for what you need, publish and override the config first, then swap a bound interface in a service provider, then open an upstream issue. Patches to vendor/ vanish on the next composer install.
• Version-drift documentation. With a compatibility-only release, docs and examples may still reference Laravel 7 APIs. Sanity-check any snippet against Laravel 8 idioms before copying it into your codebase.