Laravel Web Push Laravel Package

Getting Started

This release is primarily a compatibility release: PHP 8 support, Laravel 8 dependency upgrades, and removal of PHP 7.1/7.2. There are no new APIs documented, so treat 1.1.0 as the "modern stack" line and pin accordingly.

1. Check your runtime before upgrading.

   php -v                       # must be >= 8.0
   composer show vendor/package --all   # inspect available versions + constraints
   

   If you are on PHP 7.1/7.2 or Laravel ≤7, stay on the 1.0.x line — 1.1.0 will not resolve.

2. Read the package's composer.json first, then the README. The dependency bump to Laravel 8 is the single most important detail: it tells you which illuminate/* constraints the package will tolerate, and therefore whether it can coexist with your app's other packages.

3. Install and confirm auto-discovery.

   composer require vendor/package:^1.1
   php artisan about            # Laravel 8: confirm provider is discovered
   

   If the package predates Laravel 5.5-style discovery, register the provider manually in config/app.php.

4. First use case: publish the config (if the package ships one), then exercise a single code path in php artisan tinker or a throwaway feature test before wiring it into application code:

   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
   php artisan config:clear
   

5. Where to look when something is wrong: src/ServiceProvider (bindings, singletons, config merge), config/*.php (defaults and env keys), tests/ (the package's own CI matrix shows the supported combinations), and the new GitHub Actions workflow if you need to mirror their environment.

Implementation Patterns

Resolve from the container, not from new. Packages that support Laravel 8 almost always register a binding or singleton in their provider. Inject the contract or concrete class into controllers, jobs, and console commands so tests can swap it:

public function __construct(private PackageClient $client) {}

Keep configuration out of code. Publish the config and drive it from .env. Laravel 8's config caching means any env() call made outside a config file will return null in production — a classic post-upgrade failure.

Test against the matrix the package supports. Since 1.1.0 adds GitHub Actions and PHP 8 support, mirror it locally and in your own pipeline:

strategy:
  matrix:
    php: ['8.0', '8.1']
    laravel: ['8.*']

Run both composer update and composer update --prefer-lowest — the latter catches under-constrained dependencies that the package's own CI may not exercise.

Treat the upgrade as a two-step. Upgrade the package on a branch, run your full suite, then upgrade Laravel if you have not already. Doing both simultaneously makes bisecting failures much harder.

Wrap third-party calls behind your own service. Because this release is compatibility-focused, the public surface is stable — a thin adapter class around the package gives you a seam for fakes and a single place to change if a future major bumps APIs.

Queue and job integration. If you dispatch jobs that serialize package objects, verify serialization after upgrading: Laravel 8 tightened some model/job serialization behaviour, and PHP 8 changed how certain objects stringify.

Gotchas and Tips

• PHP 7.1/7.2 are gone. If your CI or a downstream consumer still runs 7.x, Composer will fail with an unhelpful constraint error. Set config.platform.php in composer.json to make local resolution deterministic and to reproduce CI failures locally.
• Laravel 8 dependency bumps cause transitive conflicts. When composer require fails, use composer why-not vendor/package 1.1.0 and composer depends illuminate/support rather than guessing. Common culprits: another package pinning illuminate/support: ^5.8|^6.0|^7.0.
• PHP 8 behaviour changes bite silently. Named arguments mean you must not rely on the package's parameter names staying stable — always pass positionally unless the README documents the names. Stricter type juggling can turn previously-coerced values into TypeErrors.
• PHP 8.1 deprecations. "Supports PHP 8" in the release notes generally means 8.0 was tested; 8.1 return-type deprecations may still emit notices. Check the Actions workflow for the exact versions in the matrix before assuming 8.1 is clean.
• Config caching. Always php artisan config:clear after publishing or editing config, and never call env() outside config files.
• Debugging provider issues. php artisan about (Laravel 8) lists discovered packages; composer dump-autoload after manual registration changes; php artisan package:discover if a provider silently fails to register.
• Extension points. Prefer the package's published config and container bindings over subclassing internals. If you must extend, bind your subclass in AppServiceProvider::register() after the package provider — ordering matters for singletons.
• Vendor the lockfile discipline. Commit composer.lock for applications, and after upgrading re-run your test suite with --prefer-lowest to confirm the package's declared minimums actually work.