Focus Point Bundle Laravel Package

Getting Started

Install with Composer and confirm the platform constraint resolves to the new release:

composer require vendor/package:^1.0.3
php artisan about          # verify the package appears in the discovered list

Three places to look before writing any application code:

1. The README quickstart — the copy-paste block is almost always the supported happy path.
2. The service provider (register() and boot()), which tells you what gets bound into the container, what publishes, and what is auto-discovered.
3. The published config file — its defaults are the real API surface; anything you override is a contract you now own.

First use case: wire the package into a throwaway route or php artisan tinker session and drive one complete end-to-end call — configure, invoke, observe the output. Doing this before it touches a real feature confirms the install, the config publish, and the container bindings all in one shot.

Implementation Patterns

Wrap, don't sprinkle. Bind the package's client/manager into a thin adapter of your own and resolve that from the container. Day-to-day this means the package's namespace appears in one file, and swapping or upgrading it later is a one-file change instead of a grep across the codebase.

// app/Providers/AppServiceProvider.php
$this->app->singleton(MyAdapter::class, fn ($app) => new MyAdapter(
    $app->make(PackageClient::class),
    config('package.timeout'),
));

Config through env, never through vendor. Publish once, commit the published file, and read values via config() with env() only inside config/. This is what keeps php artisan config:cache from silently breaking production.

Constructor injection over facades in anything you intend to unit test; reserve the facade for Blade templates, Artisan commands, and one-off scripts where the resolution ceremony is noise.

Test the boundary, not the package. Use the package's fake/swap hook (if it ships one) or bind a mock of your adapter in the container. Add one integration test that hits the real thing against a test credential so a version bump surfaces breaking behaviour in CI rather than in production.

Deploy checklist. If the package dispatches jobs or listeners, php artisan queue:restart after deploying; if it registers scheduled work, confirm schedule:list still shows it after the upgrade.

Gotchas and Tips

• 1.0.3 adds PHP 8.0 support — treat it as a compatibility floor, not a target. Bump your composer.json constraint explicitly (^1.0.3); a bare composer update can leave you on an older 1.0.x that never declared 8.0. Add 8.0 to your CI matrix only if you genuinely must support it; 8.0 is end-of-life, so run 8.1+ in production and keep 8.0 as a floor test if at all.
• Config caching will freeze your env() reads. If something behaves differently locally versus production, run php artisan config:clear and retest before you start debugging the package itself.
• Published files don't update themselves. After a version bump, diff the package's config/ and migration stubs against what you published; re-publish with --force only after reading the diff.
• Auto-discovery is easy to break. If you've added the provider to bootstrap/providers.php (or config/app.php) and left dont-discover unset, you can end up double-registering listeners. Check for duplicate side effects when debugging anything that fires twice.
• Pin exactly in applications, loosely in libraries. ^1.0.3 in an app with a committed composer.lock; a wider range if you're the one publishing.
• Extension point to reach for first: most Laravel packages expose a manager with an extend()/macro hook. Before forking or subclassing, check whether the behaviour you need can be registered through the container binding instead — it survives upgrades far better.