Advantasms Laravel Package

Getting Started

This release is a compatibility drop-in — it widens the supported PHP range to 7.4 and 8.0 rather than adding API surface. Start there before reading any features.

1. Confirm the constraint actually widened. Run composer show <vendor>/<package> and inspect the php requirement now recorded. If your app is on PHP 8.0 and you were previously pinning the package back (or skipping it), the blocker is likely gone; if you are on PHP 7.4, verify the package still resolves and does not silently pull a dependency that requires 8.0+.
2. Check the Laravel constraint, not just the PHP one. A package advertising 7.4–8.0 support is typically aligned with the Laravel 8.x era (laravel/framework broadly ^8.0). Before adopting, check the package's illuminate/* constraints against your app's framework version — this is the more common source of composer update conflicts than PHP itself.
3. Look first at composer.json, the README install block, and CHANGELOG. With a compatibility-only release, those three files tell you nearly everything: the exact supported matrix, whether a service provider is auto-discovered, and whether any config file needs publishing (php artisan vendor:publish --provider="...").
4. First use case: take the smallest realistic integration in your app — bind/inject the package's main class in a single controller or command, exercise it under php artisan tinker or a throwaway route, and confirm it behaves on your target runtime. Because this release has no new features to showcase, the point of the first use case is validating the environment, not exploring capability.

If you have no prior assessment to build on, treat this pass as environment qualification: get it installed, get one call path working, and record which PHP/Laravel versions you actually verified.

Implementation Patterns

Pin the boundary you tested, not the boundary you were promised. "Supports 7.4 and 8.0" is a range claim from the maintainer; your composer.json should reflect what your CI actually exercised. A practical pattern:

"require": {
    "php": "^7.4|^8.0",
    "<vendor>/<package>": "^1.3"
}

The ^1.3 floor matters — earlier 1.x lines predate this compatibility work, so an old lockfile that resolves to 1.2.x gets you none of the benefit.

Run a CI matrix across both ends of the range. For a package whose headline feature is a dual-runtime guarantee, single-version CI is the most common way teams get burned. A GitHub Actions matrix of php: ['7.4', '8.0'] against your lowest supported Laravel version is the highest-value test you can write for this release — it catches the exact class of bug the maintainer was fixing, plus the ones they missed.

Use config.platform.php to test the low end deliberately. If your production fleet is 8.0 but the package claims 7.4, add a job with "config": { "platform": { "php": "7.4.33" } }. This surfaces dependencies that quietly assumed 8.0 syntax or behaviour without you having to maintain a 7.4 container.

Isolate the package behind your own boundary. Wrap calls in a thin service class or facade of your own and bind it in a service provider. This is standard Laravel hygiene, but it is disproportionately valuable for packages on a wide PHP range: if a runtime-specific bug appears on one version only, you have a single seam to swap, shim, or conditionally stub.

// app/Providers/AppServiceProvider.php
$this->app->bind(MyWrapper::class, fn ($app) => new MyWrapper(
    $app->make(\Vendor\Package\Client::class)
));

Keep static/facade calls out of domain code. Wide-compatibility packages often ship facades for convenience. Facade calls are hard to stub in tests and hard to version-shim; resolve through the container instead so a future major bump is a provider change rather than a codebase-wide find-and-replace.

Treat version bumps as lockfile-review events. For compatibility releases, run composer update <vendor>/<package> --with-dependencies -W and read the diff of composer.lock before merging. A widened PHP constraint frequently lets transitive dependencies float to newer versions — that ripple, not the package itself, is what usually breaks the build.

Gotchas and Tips

PHP 7.4 is end-of-life (Nov 2022) and receives no security patches. The fact that this release still claims 7.4 support is a statement about the maintainer's compatibility floor, not a recommendation. If you are adopting this on 7.4, document it as technical debt with an owner and a date; if you are on 8.0, note that 8.0 itself left security support in Nov 2023 — you are buying headroom, not modernity.

Dual-runtime support constrains the package's internals, and occasionally leaks. A library targeting 7.4 cannot use enums, readonly properties, never, or first-class callable syntax, and one targeting 8.0 should avoid 8.1+ features. Practical consequence: you may hit missing niceties (no native enums in its public API, array-based config instead of typed DTOs) and shouldn't file those as bugs — they are the cost of the support matrix. Conversely, if you write your own extension or subclass against this package, your code is free to use 8.0 features only if your app floor is 8.0.

Watch for PHP 8.0 deprecation noise that is not the package's fault. Passing null to non-nullable internal parameters, and strlen(null)-style calls, were deprecated in 8.1, not 8.0 — but many packages "supporting 8.0" were never run under E_DEPRECATED strictness. Set error_reporting(E_ALL) in a local test run and read the warnings; they tell you how much real 8.x testing the package received beyond the CI green check.

Type-juggling differences bite silently. PHP 8.0 changed comparison semantics for numeric strings and made several internal function signatures stricter. If this package does config-value coercion, sorting, or numeric parsing, add explicit test cases with numeric-string inputs rather than trusting the compatibility claim.

Debugging install failures. If composer require fails, run composer why-not <vendor>/<package> 1.3.0 — it names the exact package and constraint blocking you, which is almost always a transitive php or illuminate/support requirement rather than the package under review. composer depends and composer prohibits php give the complementary view.

Verify auto-discovery before hand-registering. Laravel's package auto-discovery means a manual providers entry in config/app.php is usually redundant and can cause double-registration. Check bootstrap/cache/packages.php after composer dump-autoload to see what Laravel actually discovered.

Extension points are the right hedge against an unknown roadmap. For a compatibility-only release with no feature notes, prefer integration styles that survive a major version: bind interfaces you own, avoid subclassing concrete package classes, and keep any package-specific config in a single published config file rather than scattered env() calls. When v2.0 drops 7.4, your migration is then a constraint change plus one wrapper file.

What this release does not tell you. There is no evidence here about bug fixes, security patches, or behavioural changes — "update to support PHP 7.4 and 8.0" may or may not include internal refactors. Read the full diff between the previous tag and v1.3.0 (not just the release note) if the package touches auth, payments, or serialization; and re-run your integration tests on both runtimes rather than assuming a compatibility release is behaviour-preserving.