Fastd Eloquent Laravel Package

Getting Started

• Check the runtime floor first. v2.0.0 raises the minimum to PHP 7.2.5. Run php -v locally and in every CI image (php:7.2, older Debian/Ubuntu bases often ship 7.2.0–7.2.4) before composer require.
• Confirm the dependency line. The package tracks the illuminate/database 6.20.* line. Inspect with composer show <vendor>/<package> and composer why illuminate/database; it will not mix cleanly with an 8.x/9.x database component.
• Install and wire up. composer require <vendor>/<package>:^2.0, then publish anything it ships: php artisan vendor:publish --provider="<Vendor>\\<Package>\\<Package>ServiceProvider" and run php artisan migrate if migrations are included. Auto-discovery usually registers the provider; verify with php artisan package:discover.
• First use case: take a single existing query/model path that touches the database, route it through the package behind a config flag, and compare output against the current implementation. This validates both the package and the patched database layer in one step.
• Where to look first: the README for the public API, and the new GitHub Action workflow — it is now the authoritative record of the supported PHP/Laravel matrix and of how the maintainers exercise the package.

Implementation Patterns

• Lock the transitive database version. Because the package pins 6.20.*, treat illuminate/database as part of your application surface: commit composer.lock, and after upgrading run composer show illuminate/database to confirm you are on a >= 6.20.11 build (the release that carries the CVE-2021-21263 fix).
• Bind, don't instantiate. Register the package's contracts in your own service provider and resolve them from the container. This keeps the package swappable and lets you $this->mock(...) it in tests without touching vendor code.
• Config-driven rollout. Publish the config file and gate new behaviour per-environment (config('package.enabled')). Laravel's config cache means you must php artisan config:clear after edits — build that into deploy scripts.
• Mirror the package's CI. Add a job matrix that matches the upstream workflow (PHP 7.2.5–7.4 against the 6.x database line) so a dependency bump in the package is caught by your own pipeline rather than in production.
• Security hygiene in CI. Add composer audit (or a roave/security-advisories dev dependency) to fail builds on known-vulnerable transitive packages — exactly the class of issue this release fixes.
• Integration tip: if you use the package inside queued jobs or console commands, resolve it per-job rather than serialising service instances; long-running workers won't pick up a container rebind otherwise.

Gotchas and Tips

• The PHP bump is a breaking change in all but name. Anything on 7.2.0–7.2.4 will fail composer install after upgrading. Pin your base images explicitly (php:7.2.5-cli or newer) and re-check Dockerfiles, not just composer.json.
• composer update may not move the database package. If your root composer.json constrains illuminate/* tightly, the CVE fix can remain unresolved despite the release note. Verify the actual installed version, not the constraint, and check the lockfile diff in code review.
• CVE-2021-21263 is a query-binding issue. After upgrading, enable the query log (DB::listen(...)) on a staging path that uses raw/parameterised queries and confirm bindings render as expected — this catches both a stale dependency and any code that hand-builds SQL around the package.
• Laravel 6 is end-of-life (security support ended September 2022). A package still pinned to 6.20.* is a maintenance risk: budget an upgrade path and watch for a v3 that moves to a supported framework line. The new CI workflow is a good signal the project is still maintained — check its branch/version matrix.
• Debugging: php artisan tinker plus the package's own test suite is the fastest route; the newly added GitHub Action shows the exact command the maintainers use to run tests, so copy it rather than guessing.
• Extension points: override published config and bind interfaces in your own provider. Never patch vendor/ — the next composer update silently reverts it, and you lose the security fix you just gained.
• Release notes are thin. This release documents infrastructure and dependency changes only; no public API changes are listed. Treat the API as unchanged from v1.x but confirm against the README/tests before assuming backward compatibility.