Ezsmartcacheclear Bundle Laravel Package

Getting Started

This is a 0.1.0 release with no published release notes, so treat the source and README as the only source of truth. Before writing any application code, do a five-minute read of the repository in this order:

1. composer.json — package name, PHP constraint, illuminate/* version ranges, and the extra.laravel.providers / extra.laravel.aliases block (this tells you whether auto-discovery is wired up or you must register manually).
2. README.md — the documented entry point. If the README is thin at 0.1.0, the tests/ directory is usually the better example set.
3. src/ — locate the service provider and the main public class/contract. Anything under src/Contracts or src/Facades is API surface; anything under src/Support or src/Concerns generally is not.
4. config/*.php — the keys you will actually be expected to touch, and their env-var fallbacks.

Install pinned rather than floating, because pre-1.0 semver permits breaking changes in the minor position (0.1.0 → 0.2.0):

composer require vendor/package:0.1.*

Then publish whatever the package ships and confirm discovery worked:

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

First use case: find the smallest documented call in the README and execute it in php artisan tinker before wiring it into a controller. At 0.1.0 you want to confirm the container binding resolves and the config is read correctly before you build a feature on top of it.

Implementation Patterns

Wrap it in one adapter class. Bind a thin App\Services\... wrapper in your own service provider that delegates to the package. Day-to-day this costs nothing, and it means a 0.2.0 breaking change is a one-file edit rather than a grep across the codebase. This is the single highest-value pattern for an unversioned pre-1.0 dependency.

Config-first, then code. Publish the config file, commit it, and drive behavior from config/your-package.php with env() fallbacks. Resist passing constructor arguments at call sites — for most Laravel packages the config file is the intended customization seam and it survives upgrades better than subclassing.

Prefer constructor injection over facades. Resolve the package's contract or main class through the container in a constructor or method signature. Facades work, but they hide the dependency and make it harder to swap in a fake during tests.

Isolate side effects in jobs. If the package performs HTTP calls, writes files, or talks to a third-party API, call it from a queued job with retries and a timeout rather than inline in a request. Check the source for existing queue support before writing your own wrapper — some packages ship jobs already, and duplicating that layer causes double-dispatch bugs.

Testing. Look for a fake(), swap(), or ::preventStray... style helper in the package first; if there is one at 0.1.0, use it. Otherwise bind a Mockery instance of the contract into the container in your setUp(), and use Http::fake() for any outbound traffic. Assert on your adapter's behavior, not the package's internals.

Hook via events, not inheritance. If the package dispatches events, listen rather than extending its classes. Subclassing a 0.1.0 class ties you to its protected method signatures, which are the first thing to change in a patch release.

Gotchas and Tips

• No BC promise. 0.1.x means patch releases should be safe and minor releases may not be. Pin with 0.1.*, commit composer.lock, and read the diff on every composer update. Run the test suite before merging the lockfile bump.
• The empty changelog is itself a signal. With no release notes you cannot distinguish a feature drop from a hotfix. Diff src/ between versions (composer diff or a plain GitHub compare) before upgrading.
• Publish tags vary. If --provider= copies nothing, run php artisan vendor:publish with no arguments to list available tags, then target one (--tag=config). Many packages only register tags, not a provider key.
• Config caching breaks closures. If the published config contains a closure, php artisan config:cache will fail in production but work locally. Replace closures with a class-string or a container binding.
• Discovery caching. After any composer require/remove, if the class "does not exist" or the facade is unbound, run composer dump-autoload && php artisan package:discover. In containerized deploys this must happen during the build, not at runtime.
• Version constraint conflicts. illuminate/* ranges are the usual culprit when composer require fails against a newer Laravel. Don't force it with --ignore-platform-reqs; check whether the package supports your framework version at all — at 0.1.0 it often does not.
• Migrations may be package-loaded. Check whether migrations run from database/migrations inside the package or must be published. Never edit a published migration that the package still ships; you will silently diverge from upstream.
• Debugging binding failures. BindingResolutionException almost always means the provider is not registered or is registered after a class that needs it. Use php artisan about to confirm the provider is loaded, and app()->bound(SomeContract::class) in tinker to confirm the binding.
• Extension points to check for, in order of stability: config values → published views/translations → events → container bindings → macros → subclassing. Stay as far left as you can.
• Watch the dependency count. A 0.1.0 package pulling in heavy transitive dependencies is a long-term maintenance cost. composer why vendor/package before committing.