Laravel Approvable Laravel Package

Getting Started

• Check your runtime before anything else. 1.2.0 pins php@^7.2 and laravel/framework@^5.8|^6.0. If you are on PHP 7.1 or Laravel ≤ 5.7, composer require will simply refuse to resolve — stay on a pre-1.2 tag or upgrade the host app first. Laravel 6.x is the safer long-term target (LTS) if you are planning the jump anyway.
• Install and let discovery do its job. composer require <vendor>/<package>. Laravel 5.5+ packages normally ship extra.laravel.providers / aliases, so no manual registration is needed. Check the package's composer.json for that block first; only touch config/app.php if it is absent.
• Publish before you configure. Run php artisan vendor:publish --provider="Vendor\Package\ServiceProvider" (add --tag=config / --tag=migrations to be selective). Read the published config top-to-bottom once — it is usually the fastest map of what the package can actually do.
• First use case: get one end-to-end path working against a local database — a single read, a single write — before wiring it into anything else. That surfaces migration, config, and container-binding problems in isolation instead of in the middle of a feature branch.

Implementation Patterns

• Resolve from the container, not with new. Type-hint the package's contract/class in controllers, jobs, and commands. This is what makes the package swappable and fakeable; hard-coding new PackageClient() in a controller is the most common thing that makes a codebase hard to test later.
• Keep config in config/, secrets in .env. Published config files should reference env('PACKAGE_KEY') values, not literals. Never edit files under vendor/ — a composer update will silently discard the change.
• Wrap write operations in jobs/transactions. Anything the package does that touches the DB or an external API belongs behind a queued job or at minimum a DB::transaction(). This gives you retries and keeps request latency predictable.
• Test with fakes and RefreshDatabase. Bind a fake implementation in the test container ($this->app->instance(...) or $this->mock(...)), and use Bus::fake() / Http::fake() so tests do not hit live services.
• Centralize usage behind a thin application-level wrapper. One service class that delegates to the package means a future major version only touches one file, not forty call sites.
• Integration tip: if the package emits events or exposes hooks, prefer subscribing to those over subclassing its internals.

Gotchas and Tips

• Install failures are almost always the constraint, not the package. When resolution fails after 1.2.0, run composer why-not <vendor>/<package> 1.2.0 — it tells you exactly which dependency is holding PHP or Laravel back. Do not "fix" it with --ignore-platform-reqs; you will get runtime fatals instead of a clean error.
• Double registration. If the provider is auto-discovered and you added it to config/app.php, you get duplicate bindings and confusing "already registered" behavior. Remove the manual entry.
• Config caching. After publishing or editing config on a deployed environment, php artisan config:cache must be re-run (or config:clear locally). A stale cached config is the classic "my .env change did nothing" bug.
• Migrations on deploy. Published migrations are yours to manage; run php artisan migrate --force in the deploy pipeline and make sure rollbacks are safe before you rely on them. Check whether the package's migrations are idempotent — re-publishing can otherwise produce duplicates.
• Pin and commit. Commit composer.lock. Because 1.2.0 only relaxes/advances platform requirements, the patch-level diff is low risk, but a ^5.8|^6.0 range means an unattended composer update can move you across the 5.8 → 6.0 boundary. Review Laravel's own upgrade guide for that jump separately.
• Extension points to prefer: container bindings (custom implementations), published config, and any documented driver/manager interface. Treat protected methods and @internal classes as off-limits — they are the first thing to break in a minor release.
• Note on this release: 1.2.0 is a dependency-floor bump only — no new features, no deprecations, no API changes documented. The practical impact is purely "who can install it," so the upgrade risk is low and the assessment above is unchanged in substance.