Laravel Scout Database Driver Laravel Package

Getting Started

This release (0.4) is a compatibility release: it adds Laravel 13 support. Treat ^0.4 as the minimum version for any Laravel 13 project.

1. Confirm your framework version with php artisan --version and composer show laravel/framework.
2. Install or upgrade: composer require <vendor>/<package>:^0.4, or if already present, composer update <vendor>/<package> --with-dependencies.
3. Open the package's composer.json and read the illuminate/* constraints. Confirm ^13.0 is allowed and note the minimum PHP version — Laravel 13 raises the platform floor, and your app, local environment, and CI must all match it.
4. Look first at the README and the package service provider in src/. Standard Laravel packages register bindings, config, migrations, and commands there. If a config file is published, run php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider".
5. First use case: wire the package into a fresh Laravel 13 app, run php artisan about, and exercise one end-to-end path (a command, facade call, or route) before integrating it into a larger feature.

If you are upgrading an existing Laravel 12 app, upgrade the framework first, get the app green, then bump this package. Do not conflate the two changes in a single commit.

Implementation Patterns

• Compatibility-gated adoption. Keep the package constraint aligned with your framework constraint. In a Laravel 13 app use ^0.4; in a Laravel 12 app stay on the last 0.3.x release unless the package's composer.json declares a wider range.
• CI matrix. Add Laravel 13 to your test matrix alongside the versions you still support. Include composer update --prefer-lowest and --prefer-stable jobs to catch constraint errors early.
• Upgrade branch workflow. Create a branch, bump the package, run composer update <vendor>/<package> -W, then run the full suite with php artisan test. If resolution fails, use composer why-not laravel/framework 13.* to find the blocker.
• Service provider and facade usage. Inject dependencies in constructors and controllers; resolve facades only in views or legacy code. If the package binds an interface, bind your own implementation in a service provider rather than editing vendor code.
• Config over code. Publish config and override via .env-backed values. Keep published config in version control and diff it after each package upgrade — 0.x releases can add or rename keys.
• Queue and console integration. If the package registers commands or jobs, run php artisan list and php artisan queue:work in staging after upgrading. Container and console-kernel changes in new Laravel majors are the most common source of subtle breakage.
• Testbench for package-level tests. If you maintain extensions around this package, test against Laravel 13 with an Orchestra Testbench version matching the framework major.

Gotchas and Tips

• 0.x semver. Version 0.4 is pre-1.0: minor bumps may include breaking changes. Read the full changelog, not just the headline; "Laravel 13 support" often ships alongside dependency bumps and small API adjustments.
• Support added does not mean old support dropped. Confirm the package's composer.json still allows the Laravel versions you run. Do not assume Laravel 12 support was removed — and do not assume it was kept.
• Platform requirements. Laravel 13's PHP floor may be higher than your local or CI PHP. Check php -v and your composer.json require.php before debugging package code that is actually a platform mismatch.
• Stale caches. After upgrading, run php artisan config:clear && php artisan cache:clear && php artisan package:discover. Package discovery is cached, and a missed provider is the usual "class not found" cause.
• Transitive dependencies. composer why-not is your friend. A third-party package pinned to illuminate/support ^12.0 will block the upgrade even when this package is ready.
• Deprecations. Run tests with E_ALL and check storage/logs/laravel.log for deprecation notices from Laravel 13 and the current PHP minor. Fix them now; they become errors in the next major.
• Debugging. Use composer show <vendor>/<package> --all, composer outdated, and vendor/bin/testbench (if offered) to isolate whether a failure is in the package or your app. Use php artisan tinker to hit the package's public API directly.
• Extension points. Prefer the package's published config, events, and container bindings over subclassing internals. If you must extend, pin the exact patch version in composer.lock and add a contract test so the next 0.x bump fails loudly.
• Production pinning. Deploy with composer install --no-dev --optimize-autoloader from a committed lock file; do not let a CI composer update silently pull 0.5.