Laravel Commentable Laravel Package

Getting Started

This release is a compatibility milestone rather than a feature drop: 1.1.0 adds PHP 8 support. Treat the upgrade as an environment and CI change first, then validate package behavior under PHP 8.

1. Check your runtime constraints. Confirm your application and CI images run PHP 8.0+ before requiring ^1.1. If you are still on PHP 7.x, stay on the previous package line until the app is upgraded.
2. Update the dependency.

   composer require <vendor>/<package>:^1.1 --with-all-dependencies
   

   Use --with-all-dependencies so transitive constraints are recalculated against the new PHP requirement.
3. Look first at composer.json. Verify the package's require.php constraint, Laravel framework constraint, and whether the service provider is still listed under extra.laravel.providers for auto-discovery.
4. Re-publish configuration only if needed. Run php artisan vendor:publish --provider="<Vendor>\\<Package>\\<PackageServiceProvider>" --tag=config and diff against your existing config rather than overwriting it. Config keys are usually stable in a minor release, but PHP 8 can expose type-sensitive defaults.
5. First use case: take the package's simplest entry point — typically resolving the service from the container or calling its facade — and run it in php artisan tinker under PHP 8 to confirm the package boots and autoloads cleanly.

If there is no existing assessment, this is also the moment to record the supported PHP/Laravel matrix, the package's primary abstraction, and the one workflow your team will use it for.

Implementation Patterns

Resolve through the container, not new. Laravel packages generally bind their core service in the provider. Prefer constructor injection or app(Contract::class) so PHP 8's stricter type handling and any package-level union/intersection types are enforced consistently.

public function __construct(private PackageService $service) {}

Wrap package calls behind a small application service. This is especially valuable when adopting a PHP 8 compatibility release: if the package changes signatures or adds typed parameters, your call sites remain stable. Keep the package's DTOs and exceptions from leaking into controllers.

Use it in jobs and listeners where the package is I/O-bound. A common day-to-day pattern is dispatching package work through queued jobs so retries and backoff are handled by Laravel rather than the package. Serialize only identifiers into the job payload, then resolve the package service inside handle().

Test with the package's fake or a bound stub. If the package ships a fake, swap it in setUp(); otherwise bind a mock of its contract in the container. Run the suite on PHP 8 in CI — this is the main thing 1.1.0 changes for you.

Integration tip: add PHP 8.0 (and 8.1/8.2 if you support them) to your CI matrix alongside your existing PHP version for one release cycle. That catches deprecation notices emitted by the package before they become failures in a future major.

Gotchas and Tips

• This is a floor, not a ceiling. "PHP 8 support" usually means the package now declares php: ^8.0 (or >=8.0). Confirm the exact constraint: if it dropped PHP 7.x, the upgrade is breaking for any consumer still on 7.4 even though the version bump is minor.
• Lockfile drift. After upgrading, commit composer.lock and check composer why-not php 8.0 if resolution fails. A sibling dependency pinned to PHP 7 is the usual culprit, not this package.
• Deprecations are noisy, not fatal. PHP 8 turns many notices into deprecations. Run php -d error_reporting=E_ALL artisan test and scan logs; fix package-originated deprecations by upgrading rather than suppressing.
• PHP 8 language changes can surface in package boundaries. Named arguments, constructor property promotion, and stricter TypeError behavior mean previously tolerated null or string-to-int coercions may now throw. Audit any code that passes untyped config values into package methods.
• Clear caches after upgrading. php artisan config:clear && php artisan cache:clear && composer dump-autoload -o. Stale cached config or a stale autoloader is the most common cause of "it works in tinker but not in the app."
• Auto-discovery can be disabled. If your app sets extra.laravel.dont-discover, the provider will not register after the upgrade — register it manually in config/app.php.
• Extension points: prefer the package's published config and bound contracts over subclassing internals. Minor releases rarely guarantee internal class stability, and PHP 8 type additions make subclass signature mismatches more likely.
• Pin and stage. Roll out to staging on PHP 8 first, then production. Keep the previous constraint handy ("<vendor>/<package>": "1.0.*") so a rollback is a one-line composer change.