Laravel Cfcache Laravel Package

Getting Started

• Install with composer require nexxai/laravel-cfcache and, if the package ships a config file, publish it (php artisan vendor:publish --tag=cfcache-config). Check the README for the exact tag — the package is small, so the README is the canonical source of truth.
• First place to look: run php artisan list and grep for the package namespace (e.g. php artisan list | grep cfcache). That reveals the exact command signatures, arguments, and options you'll be wiring into app code.
• First use case on v1.6.0: the headline change is that the package's commands can now be invoked programmatically from inside the application, not just from the console. The quickest sanity check is to call the command from php artisan tinker (via Artisan::call(...)) or from a throwaway route, confirm the same behaviour you get on the CLI, then move it into a service class, listener, or job.

Implementation Patterns

• CLI-first, then wrap. Keep using the artisan command directly in deploy scripts and cron, and treat the new programmatic path as a thin wrapper around the same operation. Don't fork logic — if the package exposes a facade or service class, prefer that over Artisan::call(); otherwise Artisan::call('cfcache:...', $args) plus Artisan::output() is the pragmatic route.
• Event-driven invalidation. The main day-to-day win is hooking the command into model observers or domain events (e.g. after publishing content, updating settings, or deploying), so cache management stops being a manual step.
• Queue it. Wrap the programmatic call in a queued job when it's triggered from a web request. Cache operations are usually I/O-bound against an external service; blocking a user request on them is the wrong trade.
• Deployment integration. Call the command from your deploy pipeline (Envoyer, GitHub Actions, a post-deploy artisan step) so cache state matches the release that just shipped. This is the same call you'd make from the console, now reusable inside a deploy command or custom artisan task.
• Service-class indirection. Put the call behind your own small CacheManager/CachePurger class so tests can fake it and so you have one place to swap the underlying call if the package's API shifts again.

Gotchas and Tips

• Environment parity. Programmatic invocation runs under the web/app context, not the console. Anything the command relies on — env vars, credentials, working directory, output buffering — must be present in that context too. If it works in php artisan but not in a request, this is almost always why.
• Capture output and check the exit code. Artisan::call() returns the exit code and swallows output into Artisan::output(). Log both; a silent non-zero exit is the classic "cache wasn't purged and nobody noticed" bug.
• Config caching. If the package registers config or commands, run php artisan config:clear after publishing/updating, and remember production runs with a cached config — new config keys added in a minor release won't appear until you re-cache.
• Credentials and rate limits. Guard API keys in .env, never commit them, and be mindful of provider rate limits if the command hits an external API — batching or debouncing calls from observers matters at scale.
• Testing. The programmatic call makes this much easier to test, but stub the underlying service so CI doesn't hit a real endpoint. Assert on the exit code / facade spy rather than on rendered console output.
• Extension points. If the release exposes the command via a facade or container binding, bind your own implementation in a service provider for testing and for environment-specific behaviour, rather than subclassing the command.
• Version pinning. This is a feat: minor bump — no breaking changes signalled — but the programmatic API is new surface area. Pin to ^1.6 and skim the changelog on each minor in case the invocation contract tightens.