Json Api Auth Laravel Package

Getting Started

• Install and confirm the version. Pull 1.1.0 explicitly (composer require <vendor>/<package>:^1.1) so you pick up the new Laravel 9 support rather than resolving to an older tag. Check composer show <vendor>/<package> afterwards to confirm what actually landed in composer.lock.
• Verify framework compatibility before anything else. 1.1.0 is the first line advertising Laravel 9, so confirm illuminate/support (or laravel/framework) in the package's composer.json allows ^9.0, and that your app's PHP is >= 8.0 — Laravel 9's floor. If you are still on Laravel 8, the same tag should remain usable, but read the constraint rather than assuming.
• Let auto-discovery do its job, then clear caches. Run php artisan package:discover and php artisan config:clear after install. If the package ships a config file, php artisan vendor:publish --provider="Vendor\Package\ServiceProvider" (or --tag=config) and read it top to bottom — the defaults are the de facto documentation.
• Where to look first, in order: README quickstart → the published config file → src/ entry point (service provider and the main facade/class) → the package's own tests/ directory. Tests are the most honest usage examples you will get, especially for a release whose notes say only "changed some internal methods."
• First use case: wire up the single "happy path" from the README inside a throwaway artisan command or a Pest/PHPUnit test before touching application code. Resolve the package from the container rather than new-ing it, so you immediately learn whether the binding works the way you expect.

Implementation Patterns

• Resolve from the container; use facades sparingly. Constructor-inject the package's contract or main class into your own service, job, or controller. Facades are fine in controllers and Blade, but injecting keeps your code testable and makes it obvious when a future minor release renames or reshapes a binding.
• Wrap it in a thin application-level service. Create something like App\Services\YourFeatureService that owns the package calls. When 1.1.x → 1.2 arrives, you change one file instead of grepping 40 call sites. This is the single highest-leverage pattern for a package that describes its changes as "internal."
• Drive behaviour from config, not from hard-coded arguments. Anything the package exposes as a config key (endpoint, timeout, queue name, driver) should be read via config('package.key') and overridden per-environment in .env-backed config files. Avoid publishing a second config file to "customise" — override in config/<package>.php and keep the package's defaults visible in git history.
• Prefer queued jobs for anything slow. If the package performs HTTP calls, file work, or third-party writes, call it from a job with $this->tries, backoff(), and failed() defined. This is also where idempotency matters: assume the package may be retried, and guard side effects with a dedupe key.
• Test with fakes before mocks. Look for Package::fake() or an equivalent in the source; if it exists, use it in feature tests and assert against recorded calls. Fall back to $this->mock(Contract::class) bound in the container for unit tests. Always RefreshDatabase when the package touches tables, and test one real integration call against a sandbox/stub before shipping.
• Upgrade workflow for 1.1.0. Branch → composer update <vendor>/<package> → run the full suite → grep -rn "extends .*Package" app/ to find any subclass you wrote. Internal-method changes only bite you if you extended or overrode. If your suite is thin, at minimum exercise every place you call the package and diff the release's src/ against 1.0.x (git diff 1.0.0..1.1.0 -- src/ in the vendor checkout or upstream repo).

Gotchas and Tips

• "Internal methods changed" is the whole risk surface. Nothing in the notes claims a breaking change, and 1.1.0 is a minor — so public API should be stable. But anything protected/private, anything you subclassed, and anything you called that the README did not document is fair game. Treat undocumented methods as unstable and plan to re-read that diff on every minor bump.
• Pin with a caret, not a tilde-plus-hope. ^1.1 is right for a semver minor. Do not pin an exact 1.1.0 in libraries you publish; do pin exact in production if you have no test coverage and will upgrade deliberately.
• Laravel 9 is not just a constraint bump. If you are upgrading the app to L9 at the same time, separate the two changes into distinct commits/PRs. Otherwise a failure tells you nothing about whether the package or the framework moved.
• Stale caches are the classic false negative. After upgrading, run php artisan config:clear && php artisan cache:clear && composer dump-autoload. A surprising number of "the new version broke" reports are an optimised config cache holding old values.
• Config file merge semantics. If you published the config in 1.0 and 1.1 adds keys, your published copy will not have them. Compare config/<package>.php against the package's config/<package>.php after each upgrade, or delete and re-publish into a diff.
• Debug with the package's own logging first. Set the package log channel to daily/stderr, or drop ray()/logger() calls around the boundary of your wrapper service. Telescope's "Exceptions" and "Jobs" tabs are usually faster than step-debugging vendor code.
• Extend via the container, not via inheritance. If you need different behaviour, bind your own implementation to the package's contract in a service provider, or listen to the events the package dispatches. Subclassing a concrete class is exactly the pattern the "internal methods" change can break.
• Watch the deprecation surface for 1.2. A release that touches internals is often the precursor to renames. Note in your upgrade checklist which package methods you call that are absent from the README — those are your candidates for removal.