Pusher Http Laravel Laravel Package

Getting Started

• Pin the right constraint first. v4.2.4 is the release where Laravel 7 support lands, so on a Laravel 7 app require ^4.2.4 (or ^4.2 with a lockfile you refresh) rather than a bare ^4.0; on Laravel 6 you can stay on any 4.2.x. Confirm what actually resolved with composer show <vendor/package> before debugging anything else — a stale composer.lock silently keeping 4.2.3 is the most common "the new version doesn't work" report.
• Read the service provider before the README. vendor/<vendor>/<package>/src/*ServiceProvider.php tells you the bindings, singletons, deferred providers, and publish tags. That is the real API surface for a Laravel package.
• Publish what you need: php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" (or the narrower --tag= variants you find in the provider). Publish config always; publish migrations and views only if you intend to own them.
• First use case: resolve the package's main class from the container in php artisan tinker or a throwaway feature test and run the single happy-path call once. Getting one successful round-trip outside your app code makes every later failure unambiguously a wiring problem.
• php artisan about (available since Laravel 7) and php artisan package:discover are the fastest sanity checks that discovery and config are loaded.

Implementation Patterns

• Inject, don't instantiate. Type-hint the package contract in constructors and controller methods so config, bindings, and any decorators apply. new PackageClient() bypasses everything the provider set up and is the classic source of "works in tinker, fails in the controller."
• Facades for terse call sites, injection everywhere else. Facades are fine in Blade, closures, and one-liners; use constructor injection in jobs, listeners, and console commands where testability matters.
• Wrap it in one app-level service. A thin App\Services\… class that owns the package calls gives you a single seam to fake, log, or swap. Worth the extra file on anything beyond a trivial integration.
• Config over code. Keep tunables in config/<package>.php, override via .env keys referenced inside the config file, and commit the published config. Never read env() from application code.
• Queues: pass IDs, not hydrated models, into package jobs; be explicit about SerializesModels behaviour and connection/queue overrides per job.
• Testing: RefreshDatabase for anything the package persists, Http::fake() for its outbound calls (Laravel 7's client pairs well here), Event::fake() / Bus::fake() to assert the package dispatched what you expect without executing it.
• Laravel 7 leverage: where the package ships views, prefer Blade component tags over @include soup; use Str::of() fluent helpers when post-processing its string output.

Gotchas and Tips

• Constraint mismatch is the #1 failure. If Composer resolves below 4.2.4 on a Laravel 7 app, look for a competing illuminate/support constraint in your own composer.json or a transitive dependency, not a bug in the package.
• Symfony 5 fallout. Laravel 7 moved to Symfony 5; odd container or console exceptions after upgrade usually trace to a third-party dependency pinned to Symfony 4, not to this package.
• Config cache. After editing the published config: php artisan config:clear. Any env() call outside a config file returns null once cached, which turns into a silent fallback at runtime.
• Double registration. If the package auto-registers events, listeners, or scheduled tasks, registering them yourself in EventServiceProvider fires them twice. Check the provider's boot() before adding your own wiring.
• Migrations. Publish and read before migrate; check table names don't collide with existing ones, and confirm down-migrations exist before running in a shared environment.
• Debugging loop that works: package:discover → dump the resolved config (config('<package>') in tinker) → resolve the contract and dd() it → enable the query log if the package is DB-backed → wrap calls in your app service with Log::debug() in/out.
• Extension points, in order of preference: bind your own implementation to the package contract in AppServiceProvider::register(); use any macroable hooks; publish and edit config; only then consider a fork. Never edit vendor/.
• Pin versions in CI and run the suite on both Laravel 6 and 7 if you support both — 4.2.4 is exactly the release where that matrix starts to matter.