Tinker Laravel Package

Getting Started

Release 1.2.0 is primarily a compatibility release: it updates composer.json to allow Laravel 7.x. There are no runtime API changes called out, so the main first step is to confirm dependency compatibility before adopting the package.

1. Install or upgrade with Composer:

   composer require vendor/package:^1.2
   

2. Check the package’s composer.json constraints:

   composer show vendor/package
   

   Confirm it allows the Laravel version you are running, especially laravel/framework and illuminate/*.
3. If the package ships a service provider, confirm Laravel auto-discovery works, or register it manually in config/app.php.
4. Publish any package config/assets if the README calls for it:

   php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider"
   

5. First use case: upgrade a Laravel 6 app to Laravel 7, install ^1.2, then smoke-test the package’s primary workflow rather than assuming Composer compatibility equals runtime compatibility.

Where to look first: the package README, composer.json, service provider, config file, and any upgrade notes for Laravel 7.

Implementation Patterns

• Prefer constructor injection over facades for application services:

  public function __construct(private PackageService $service) {}
  

• Use facades mainly in views, legacy code, or quick scripts where DI is impractical.
• Treat configuration as the main integration surface. Publish config, then keep environment-specific values in .env rather than editing vendor files.
• If the package exposes contracts or driver managers, bind custom implementations in a service provider:

  $this->app->bind(PackageContract::class, CustomImplementation::class);
  

• For Laravel 7 upgrades, test the package in the same workflows where it is used: HTTP middleware, queued jobs, console commands, events/listeners, and scheduled tasks.
• Add a focused integration test around the package’s main use case. Composer metadata changes do not guarantee behavior under Laravel 7 in every app context.
• Use Laravel’s container and config caching in staging/production, but rebuild caches after changing package config or providers:

  php artisan config:clear
  php artisan config:cache
  php artisan package:discover
  

Gotchas and Tips

• Composer resolution is the first likely failure point. If the app is still locked to Laravel 5.x/6.x, ^1.2 may not install until laravel/framework is updated. Use composer why-not vendor/package 1.2.0 to inspect conflicts.
• Laravel 7 support does not imply Laravel 8+ support. Check the package’s constraint matrix before assuming it works on newer Laravel versions.
• Auto-discovery can fail silently. If package features are missing, verify the provider is discovered with php artisan package:discover or register it manually.
• Config cache quirks. After publishing or changing package config, run php artisan config:clear; otherwise cached config may hide new keys.
• Do not edit vendor files. Extend via published config, container bindings, custom drivers, or package events where available.
• Debugging checklist: run composer show vendor/package, composer why-not vendor/package 1.2.0, php artisan package:discover, and clear Laravel caches before deeper debugging.
• Laravel 7 is old. If this release is being used only to keep an existing Laravel 7 app running, plan an upgrade path; if starting fresh, prefer a supported Laravel version and confirm the package supports it.