Laravel Log Mailer Laravel Package

Getting Started

• Install with composer require vendor/package:^2.1. The 2.1 line is the first release that accepts Laravel 7, so on a Laravel 7 app this is your minimum constraint — ^2.0 will fail resolution with illuminate/support ^7.0.
• Confirm what you actually got: composer show vendor/package should report 2.1.x and a illuminate/support requirement of ^6.0 || ^7.0. If it still shows ^6.0, you have a stale lockfile.
• Check the PHP floor. Laravel 7 requires ^7.2.5, Laravel 6 requires ^7.2, so 2.1.0 quietly rules out anything below 7.2.5 in practice when paired with L7.
• Look first at the package's service provider — it's auto-discovered via extra.laravel.providers in the package's composer.json. Read register() for bindings/config merges and boot() for macros, Blade directives, and listeners. That split tells you the whole day-to-day surface.
• First use case: publish anything publishable (php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"), then exercise a single call in php artisan tinker before wiring it into application code.

Implementation Patterns

• The package depends only on illuminate/support, which usually signals a lightweight, framework-agnostic library: helpers, Macroable extensions on Collection/Str, custom validation rules, or a small manager class. Register its macros from your own AppServiceProvider::boot() rather than calling them ad hoc, so the extension point is discoverable.
• If it ships a facade, alias it in config/app.php — Laravel 6/7 will not auto-alias it unless the package explicitly declares extra.laravel.aliases. Prefer constructor injection over the facade in your own services so tests can substitute a fake.
• Override behaviour through $this->app->bind()/singleton() in a provider or through published config. That is the intended extension point; avoid editing vendor files.
• Cross-version CI is the real work of a dual-support release: use orchestra/testbench ^4.0 for Laravel 6 and ^5.0 for Laravel 7, with a matrix job per framework version. A single shared lockfile defeats the purpose.
• Wrap the package in a thin application-level adapter/service if you call it from many places. When the inevitable Laravel 8 constraint lands, you change one file instead of forty.
• Keep your own config in config/your-package.php and reference package defaults rather than copying the published config verbatim, so composer update doesn't clobber your overrides.

Gotchas and Tips

• This is a compatibility release, not a feature release. The runtime API is unchanged from 2.0.x; do not go looking for new methods. If something "changed" after upgrading, it's your dependency graph, not the package.
• ^6.0 || ^7.0 will actively block Laravel 8 and will conflict with anything still pinned to illuminate/support ^5.x. Run composer update vendor/package --with-dependencies and read the solver output; the failure message names the offending package, not this one.
• Because the only requirement is illuminate/support, the package may not pull in illuminate/console, illuminate/routing, or the full framework. If you call artisan commands or routes it doesn't register, that's on your app's laravel/framework, not the package.
• Stale-lockfile symptom: on Laravel 7 you see missing-class or constraint errors even though you "upgraded". Verify with composer show vendor/package before debugging anything else.
• Debugging discovery: php artisan about or dd(array_keys(app()->getLoadedProviders())) confirms the provider actually loaded. A silently undiscovered provider looks identical to a misconfigured one.
• Respect the register() vs boot() split when extending: config merges and container bindings in register(), macros/Blade/listeners in boot(). Registering macros in register() works by accident and breaks when another provider resolves early.
• No deprecations were introduced in 2.1.0, but the Laravel 6 leg of the constraint is on a clock. Track the package's next major for Laravel 8+ and plan the lockstep upgrade now rather than at EOL.