Laravel Brickables Laravel Package

Getting Started

3.2.0 is primarily a platform-compatibility release: it adds Laravel 10 support, drops Laravel 8, and locks PHP support to 8.1 and 8.2. There are no new APIs called out in the release notes, so day-to-day usage should remain the same once your application matrix matches the supported stack.

Start by checking compatibility before touching application code:

• Confirm your app runs Laravel 10 and PHP 8.1 or 8.2.
• Inspect the package’s composer.json for the exact php, illuminate/*, and laravel/framework constraints.
• Read the package’s README, CHANGELOG, and any UPGRADING file for Laravel 10-specific notes.
• Locate the service provider, facade, config file, migrations, and published assets so you know what is auto-discovered versus manually registered.

A good first use case is a smoke-test upgrade in a non-production branch: install ^3.2, publish any config/assets if required, run the package’s main workflow, then run your application test suite with Laravel 10 on PHP 8.1 and 8.2.

Implementation Patterns

Treat 3.2.0 as a compatibility gate rather than a feature upgrade.

• Upgrade path: create a branch, update the package constraint to ^3.2, run composer update <vendor>/<package> --with-dependencies, clear caches, run migrations if applicable, and execute the full test suite.
• Multi-app environments: keep Laravel 8 applications pinned to the last compatible 3.1.x release. Move Laravel 10 applications to 3.2.x deliberately rather than relying on a global composer update.
• CI matrix: add or keep explicit jobs for Laravel 10 with PHP 8.1 and PHP 8.2. Remove Laravel 8 jobs from the 3.2.x compatibility matrix.
• Integration: follow the package’s existing registration pattern. If it uses package discovery, avoid duplicate manual provider registration. If it exposes config, publish it and keep environment-specific overrides in .env rather than editing vendor files.
• Day-to-day usage: no new public API is indicated, so continue using the package through its documented facade, dependency injection bindings, events, or helpers. Add one regression test around the package’s main integration point so future Laravel/PHP upgrades catch breakage early.
• Rollout: deploy first to a staging environment that mirrors production PHP and Laravel versions, then promote. Keep the previous lockfile available for rollback.

Gotchas and Tips

• Breaking change in a minor release: dropping Laravel 8 in 3.2.0 is a meaningful compatibility break. Do not assume a minor version bump is safe; check composer why-not <vendor>/<package> 3.2.0 if resolution fails.
• PHP 8.3 is likely blocked: the release locks PHP to 8.1 and 8.2. If your local machine or CI uses PHP 8.3, Composer will refuse the update or resolve an older package version. Use composer check-platform-reqs and set config.platform.php where appropriate.
• Laravel 8 apps must stay pinned: constrain Laravel 8 projects to the previous compatible line and avoid shared lockfiles across applications with different framework versions.
• Cache and discovery issues: after upgrading, run php artisan config:clear, php artisan cache:clear, and php artisan package:discover. Laravel 10 upgrades often surface stale cached config or package manifests.
• Test both PHP versions: Laravel 10 supports a wider PHP range than this package declares. Verify 8.1 and 8.2 explicitly rather than assuming one passing job covers both.
• Debugging resolution: use composer show <vendor>/<package>, composer outdated, and composer diagnose to confirm which version Composer selected and why.
• Extension points: prefer the package’s documented extension points—config, events, container bindings, macros, or published views—over modifying vendor code. Re-publish config or assets after upgrading if the package ships changed defaults.