Bootstrap Breeze Laravel Package

Getting Started

The only substantive change in 1.0.6 is declared Laravel 10 support — there are no documented new features, deprecations, or API changes in the release note itself. Treat this as a compatibility release and verify it rather than assume it.

Minimal steps:

1. Confirm your app is on Laravel 10 before upgrading the package. Laravel 10 requires PHP 8.1+ and pulls in Symfony 6 components, so a package that only just added Laravel 10 support has almost certainly raised its own PHP floor. Check composer.json (require.php, require.illuminate/*) rather than trusting the release title.
2. composer require <vendor>/<package>:^1.0.6 (or composer update <vendor>/<package> if already installed), then read the diff in composer.lock to see what else moved.
3. Look first at the package's src/ service provider and any config/*.php — that is where the public surface (bindings, publishable config, routes, migrations) is defined. If a config file exists, php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" and diff it against your published copy; compatibility releases frequently add keys.
4. First use case: instantiate the package's main entry point through the container (app(SomeManager::class)) in a Tinker session and exercise one read-only operation before wiring it into application code.

If you are still on Laravel 9 or below, stay on the previous 1.0.x line — 1.0.6 makes no promise of backward support.

Implementation Patterns

Because the release is a framework-support bump, the day-to-day patterns are about pinning and isolating the package correctly rather than adopting new APIs.

• Constrain in composer.json, not by hope. Use "<vendor>/<package>": "^1.0.6" and let the platform requirements (php: ^8.1, illuminate/support: ^10.0) do the gating. On a mixed-version monorepo, keep the constraint in the root only.
• Resolve through the container. Bind or alias the package's contracts in a dedicated service provider (app/Providers/PackageServiceProvider.php) rather than calling the facade directly from controllers. That gives you one seam to swap or mock when the next major lands.
• Wrap the package behind your own adapter. Even a thin App\Support\... class that delegates to the package means a future breaking change touches one file instead of fifty call sites.
• Configure via env → config. Never read env() outside config/; publish the package config and reference it with config('package.key') so php artisan config:cache stays safe.
• Test the boundary. In phpunit.xml set the package's credentials/endpoints to fakes, and add one feature test that asserts the container resolves the package's main class — this catches provider registration regressions immediately after a composer update.
• Deploy order. Upgrade in a branch, run composer update --with-dependencies, then the full suite plus php artisan about to confirm the framework/platform versions actually resolved as intended.

Gotchas and Tips

• "Laravel 10" is not a changelog. A one-line release note means the meaningful diff is in composer.json and possibly internal refactors for Symfony 6 / PHP 8.1. Read the compare view on the repo (/compare/v1.0.5...v1.0.6) before shipping.
• PHP floor moved. Laravel 10 drops PHP 8.0; if CI still runs 8.0 or 7.4, the install will fail with a confusing constraint error. Update the matrix first.
• Silent transitive breakage. Bumping the package can upgrade illuminate/* across the board. Pin laravel/framework explicitly in your app so a package update can't drive a framework minor you didn't test.
• Publishable assets drift. After upgrading, re-publish config/migrations to a temp path and diff — new config keys added without defaults will null out at runtime and fail deep inside the package rather than at boot.
• Cached config and routes. php artisan config:clear && php artisan route:clear before debugging "it works in Tinker but not in the app"; stale caches are the most common post-upgrade ghost.
• Debugging hook. If something breaks after the bump, wrap the call in a try/catch and report() the exception with getPrevious() — packages often swallow the underlying framework error.
• Extension points to prefer. Laravel's extend() on the container, Macroable traits, and published config are stable surfaces; subclassing internal, non-final classes is not. If you must patch behaviour, prefer a decorator bound in your own provider.
• Version pin discipline. Until a fuller changelog appears, pin 1.0.6 exactly in composer.lock and avoid ^1.0 in environments you can't immediately re-test; the next patch may carry undocumented changes.