Laravel Slack Blocks Laravel Package

Getting Started

• Baseline assessment for v2.3.0. There is no prior assessment; the only announced change is PHP 8 support, so treat this release as a platform-compatibility release rather than a feature release.
• First verify the runtime and framework:
  • php -v should be PHP 8.0+.
  • Confirm your Laravel version also supports PHP 8. Laravel 6.20+, 7.30+, and 8.x are the relevant baselines.
  • Check the package’s composer.json constraint: "php": "^8.0" is a hard platform bump, while "^7.4 || ^8.0" is additive support.
• First place to look: composer.json, CHANGELOG.md/UPGRADING.md, the service provider, config file, and the diff between the last v2.2.x release and v2.3.0.
• First practical use case: upgrade an existing Laravel app from PHP 7.4 to PHP 8.0, run composer update vendor/package --with-all-dependencies, then verify package registration, config publishing, artisan commands, queue jobs, and any HTTP integration still work.

Implementation Patterns

• Pin the package constraint explicitly, for example "vendor/package": "^2.3", and commit composer.lock. Avoid floating dev-main during a PHP runtime upgrade.
• Use Composer’s conflict tooling before changing runtime:
  • composer why-not php 8.0
  • composer why-not vendor/package 2.3.0
• Run a PHP-version CI matrix. At minimum test PHP 8.0; test 8.1/8.2 separately unless the release notes explicitly claim support beyond PHP 8.0.
• Configure static analysis to match the runtime, e.g. PHPStan/Larastan phpVersion: 80000, and run PHPCompatibility if the package or app must still support PHP 7.4.
• If the package supports both PHP 7.4 and PHP 8, avoid PHP 8-only syntax in application code that must run on both. Use PHP_VERSION_ID guards only where genuinely necessary.
• Integration workflow:
  • Resolve package contracts from the container rather than instantiating internals.
  • Publish and version-control package config instead of editing vendor files.
  • Exercise package events, macros, commands, and jobs in a staging environment after the PHP upgrade.
• Treat the upgrade as a deployment change: branch, bump PHP, update dependencies, run the app test suite, deploy to staging, monitor deprecation logs, then production.
• If v2.3.0 exposes no new APIs, keep application code coupled to the documented public surface rather than PHP 8-specific internals.

Gotchas and Tips

• Check whether PHP 7 support was dropped. “Adds PHP 8 support” may mean ^7.4 || ^8.0, or it may mean a hard move to ^8.0. The latter is a breaking platform change for anyone still on PHP 7.4.
• Named arguments make parameter names public API. If v2.3.0 renamed constructor or method parameters while adding PHP 8 support, downstream calls using named arguments can break. Prefer positional arguments around package APIs unless you have verified parameter names.
• PHP 8.0 removals to search for: each(), create_function(), money_format(), get_magic_quotes_gpc(), fgetss(), convert_cyr_string(), hebrevc(), ezmlm_hash(), restore_include_path(), ldap_sort(), image2wbmp(), png2wbmp(), jpeg2wbmp(), __autoload(), $php_errormsg, and track_errors.
• Reserved keyword changes: match is a keyword in PHP 8. Code using match as a class, function, or method name can fail. Also review mixed and static return-type interactions.
• PDO default error mode changed to exceptions in PHP 8. Laravel normally configures this, but custom PDO connections or package internals may behave differently.
• Locale-independent float-to-string conversion in PHP 8.0 can change serialized values, cache keys, database writes, and API payloads. Test float-heavy code and cache/session payloads.
• @ no longer silences fatal errors, and string-based assert() is no longer evaluated. Search for legacy suppression and assertion patterns.
• If the package claims PHP 8 support but Composer still conflicts, the blocker is often a transitive dependency. Use composer why-not php 8.0 and composer update -vvv.
• Debug with APP_DEBUG=true, php -d error_reporting=E_ALL, Laravel logs, and deprecation output. composer diagnose is useful for platform/extension issues.
• Extension points to prefer: service-provider bindings, published config, events, and documented macros. Avoid editing vendor code or relying on PHP 8-only behavior that the package has not documented as supported.