Clamav Bundle Laravel Package

Getting Started

The v1.0.0-beta tag ships with no changelog beyond a one-line "beta release" note, so treat the source as the specification until the maintainers publish upgrade notes.

1. Install with an explicit stability flag — beta releases are not matched by Composer's default stable minimum, so a bare composer require vendor/package will fail or silently resolve to an older tag:

   composer require vendor/package:^1.0@beta
   

2. Read these four files first, in order — composer.json (PHP/Laravel version constraints, extra.laravel.providers and aliases for auto-discovery), the README, CHANGELOG.md, and src/ root. On a beta with terse notes, src/ tells you what the README forgot.
3. Confirm discovery, then publish — if the package registers a service provider via extra.laravel, no manual registration is needed. Publish assets before writing any code:

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

   Check whether that publishes a config file, migrations, or both, and run php artisan migrate if migrations land.
4. First use case: a throwaway smoke test. Wire the package into a scratch route or php artisan tinker session and exercise the single golden path from the README end to end — resolve the binding, call the primary method, inspect the result. Do this in a disposable app, not your production codebase, so you can delete it cleanly if the beta disappoints.
5. Run the package's own test suite (vendor/bin/phpunit or pest inside vendor/vendor/package) to see which Laravel versions the maintainers actually exercise. That is a better compatibility signal than the composer.json constraint.

Implementation Patterns

• Bind to the container, don't reach for the facade. Constructor-inject the package's contract into your own service classes. If the package only ships a facade, wrap it behind a small interface of your own so a beta-to-stable API change is a one-file edit:

  final class InvoiceSyncer
  {
      public function __construct(private \Vendor\Package\Client $client) {}
  }
  

• Configure via config/package.php plus env() indirection. Publish the config, keep secrets in .env, and reference them only from the config file — never call env() outside config, or config:cache will silently return null in production.
• Push slow work onto the queue. Most Laravel packages that talk to a third party expose both a synchronous call and a queued job/listener. In a beta, prefer the queued path: it isolates failures, gets you retries and backoff for free, and keeps request latency predictable.
• Test with container swaps. In phpunit.xml, set the package's config to a fake/sandbox driver. Bind a stub implementation in setUp() and assert against your wrapper, not the vendor class:

  $this->app->instance(Client::class, new FakeClient());
  

• Pin and lock. Use an exact-ish constraint (1.0.0-beta or ^1.0@beta) and commit composer.lock. Treat every beta bump as a potential breaking change and re-read the diff before upgrading.
• Isolate the integration behind one adapter. One class that imports the vendor namespace, everything else in your app depends on that class. This is the single highest-value pattern when adopting pre-1.0 software.

Gotchas and Tips

• No semver guarantees. A 1.0.0-beta.2 can rename methods or drop config keys with no deprecation path. Budget for a re-read of the source on each bump, and don't let the vendor namespace leak into your domain layer.
• config:cache bites first. If behaviour differs between php artisan serve and a deployed environment, run php artisan config:clear && php artisan config:cache locally and re-test. Stale cached config is the most common "the package is broken" false alarm.
• Auto-discovery vs. manual registration. Packages that use discovery often still document manual registration for older Laravel versions. Registering the provider and leaving auto-discovery on produces duplicate registrations — symptoms include doubled event listeners and duplicated routes.
• Publish collisions. vendor:publish will not overwrite existing files without --force, so a config change in a beta bump may never reach your app. Diff the vendor config against yours after every upgrade.
• Migration ordering. Published migrations are timestamped at publish time, not at package release time; on an existing schema this can put foreign keys before the tables they reference. Publish and migrate on a fresh database first.
• Debugging checklist: php artisan about to confirm the provider loaded; app()->bound(SomeContract::class) in tinker; php artisan event:list if you expect the package to emit events; Laravel Telescope for the actual query/job/HTTP trail. If a facade returns something unexpected, resolve the underlying class from the container — the facade accessor is a frequent typo source in early releases.
• Extension points worth checking before you commit: container bindings published by the provider (swap the implementation), driver/manager patterns (extend() to add your own driver), macroable traits, and published events you can listen to rather than subclassing vendor internals. Prefer all four over forking.
• Report what you find upstream. On a beta with a single-line changelog, an issue or PR documenting the behaviour you relied on is cheap insurance and often lands faster than on a mature project.