Nova Notifications Laravel Package

Getting Started

This is the first assessment for this package. The only capability documented in the current release line is framework compatibility: 1.0.11 adds Laravel 6 support, so treat that as the anchor point for everything below.

1. Check your environment against Laravel 6's floor. Laravel 6 requires PHP >= 7.2 and pulls in Symfony 4.3 components plus Carbon 2. If your app is still on PHP 7.1 or Symfony 4.2, the constraint will fail before the package ever loads — verify with php -v and composer show symfony/console before touching the package.
2. Install pinned to the new floor: composer require <vendor>/<package>:^1.0.11. Anything below 1.0.11 will not have the widened illuminate/* constraint and composer update will resolve you back to an older framework.
3. Look first at composer.json, specifically the illuminate/support (and any illuminate/*) constraints, then the service provider's register()/boot() methods and any publishes() tags. For a package in the 1.0.x range, those three things tell you more about day-to-day behaviour than the README does.
4. First use case: drop it into a Laravel 6 app, confirm auto-discovery registered the provider (php artisan about or php artisan package:discover), run your existing test suite, and only then exercise the package's own API. Compatibility releases are exactly the moment to prove the integration still holds rather than to explore features.

Implementation Patterns

• Pin the patch version in composer.json for the upgrade window. "^1.0.11" is the safe constraint; "^1.0" lets Composer resolve back to a pre-Laravel-6 release on a fresh install or in CI.
• Rely on package auto-discovery, but verify it. Laravel 5.5+ discovers providers automatically, so most upgrades need no config/app.php edit. If the package was previously registered manually, remove the duplicate entry — double registration is a common source of "works locally, fails in CI" bugs after a version bump.
• Add Laravel 6 to your CI matrix explicitly. Run the suite against both your previous framework version and 6.x for one release cycle. Most regressions from this class of bump surface as deprecation notices rather than hard failures, and a matrix is the only cheap way to catch them.
• Publish config and re-diff it. If the package ships a publishable config file, republish after upgrading and diff against your existing copy. Minor releases sometimes add keys with defaults that change behaviour silently when absent.
• Wrap third-party calls behind your own binding. Bind the package's service/contract to an interface in a service provider rather than type-hinting the concrete class across your app. That way a future major version that renames or restructures the API becomes a one-line change in a provider.
• Use the package's facade/alias only at the edges. If it exposes a facade, keep it in controllers and console commands, not in domain code, so tests can swap it without booting the full container.

Gotchas and Tips

• Laravel 6 removed the global str_/array_ helpers into laravel/helpers. If the package's internals (or your own glue code) call them, add laravel/helpers to require — otherwise you get "Call to undefined function" at runtime, not install time.
• Carbon 2 is a behavioural change, not just a version bump. diffIn* methods now return floats by default and ->eq()/->neq() semantics changed. Any date handling you layer on top of the package deserves a spot check.
• Constraint conflicts are the most likely failure mode. When composer update refuses, run composer why-not <vendor>/<package> 1.0.11 — it names the exact package pinning illuminate/support below 6.0 far faster than reading the solver output.
• Clear discovery caches after upgrading: php artisan package:discover (and composer dump-autoload if you edited the provider list). A stale bootstrap/cache/packages.php will happily load the old provider class.
• Watch for silently widened constraints. Confirm 1.0.11 actually declares Laravel 6 support ("illuminate/support": "^5.5|^6.0") rather than merely installing under 6.0 via a permissive constraint elsewhere. The former is a supported configuration; the latter is a coincidence you'll pay for later.
• Extension points to prefer over patching: publishable config, container bindings for the package's contracts, and facade macro()/shouldReceive hooks in tests. Avoid subclassing package internals — a 1.0.x line has no BC promise on non-public classes.
• No breaking changes are announced in this release, so no migration work is implied — but with no prior assessment on record, confirm the package's documented support policy (semver, LTS posture) before committing to it for anything longer-lived than a single project.