Laravel Database Schedule Laravel Package

Getting Started

The 1.4.0 release is a compatibility release: it adds Laravel 11 support. Treat it as the minimum version to use on Laravel 11, and verify the upgrade path before rolling it out.

1. Confirm the host app meets Laravel 11’s baseline: PHP 8.2+, Composer 2.x, and a Laravel 11 skeleton.
2. Require or upgrade the package:

composer require vendor/package:^1.4
# or, in an existing app
composer update vendor/package --with-dependencies

3. Run the package’s publish/discovery steps if it provides them:

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

Look first at the package README, CHANGELOG.md, service provider, and any published config file. The first practical use case is a smoke test in a fresh Laravel 11 app: resolve the package’s facade or injected service, perform one read and one write operation, and confirm configuration is merged correctly. If you are upgrading from Laravel 10, repeat that smoke test in a branch before merging.

Implementation Patterns

• Auto-discovery first. Laravel 11 still uses package discovery. Confirm the service provider is registered in bootstrap/providers.php only if the package is not auto-discovered; otherwise let discovery handle it.
• Inject contracts, not facades, in application code. Resolve the package service through the container in controllers, jobs, and listeners so tests can swap implementations. Use the facade only at the edges (Blade, quick scripts, artisan commands).
• Keep package configuration environment-driven. Publish the config file once, then reference env() values in config/package.php rather than calling env() from package code. In Laravel 11, config caching is common in deployment, so verify php artisan config:cache does not break package behavior.
• Test against the package boundary. Use feature tests with the package’s real service provider and RefreshDatabase if it ships migrations. For unit tests, bind a fake implementation of the package contract.
• Queue and job usage. If the package service is stateful, resolve it inside handle() rather than injecting it into the job constructor, and confirm serialization works under Laravel 11’s queue workers.
• Upgrade pattern. Pin ^1.4, run the app’s test suite, then compare published config against the package’s current default config. Minor releases that add framework support often leave the public API unchanged, but verify the changelog rather than assuming.

Gotchas and Tips

• Laravel 11 skeleton changes. Laravel 11 removed several default config files and changed the application bootstrap. If the package expects config keys that no longer exist by default, publish the package config and merge missing keys explicitly.
• PHP 8.2 minimum. Laravel 11 requires PHP 8.2. If CI or production still runs PHP 8.1, Composer will resolve an older package version or fail; check composer why-not vendor/package 1.4.0.
• Composer constraints. Ensure illuminate/support and related constraints allow Laravel 11. If another dependency pins Laravel 10, you will get a conflict rather than a clean upgrade; use composer update --with-dependencies and inspect the solver output.
• Discovery cache. After install or upgrade, run php artisan package:discover if commands, facades, or config are missing. In deployments, clear bootstrap/cache/packages.php and services.php as part of the release step.
• Octane and long-running workers. If the package registers singletons or caches request state, verify behavior under Laravel Octane. Prefer scoped bindings for request-dependent services.
• Debugging. Use php artisan about to confirm the framework version and environment, composer show vendor/package to confirm the installed version, and the package’s own log channel or events if it exposes them. If the package provides extension points such as custom drivers, macros, or events, prefer those over subclassing internals so future minor releases remain safe.
• Rollback plan. Because 1.4.0 is the first Laravel 11-compatible release in this line, keep the previous constraint available in composer.json history so you can pin back to ^1.3 if an integration issue appears.