Encryption Laravel Package

Getting Started

The 1.1.0 release widens framework support to Laravel 5.x, 6.x, and 7.x. That single fact drives most of what follows: this is a compatibility-oriented release, not a feature release, so the first task is to confirm where you sit in that matrix before writing any integration code.

Start here:

1. Check your installed versions. Run composer show laravel/framework and php -v. Laravel 5.x runs on PHP 5.6–7.2 (5.5+ prefers 7.1), Laravel 6 and 7 require PHP 7.2+ (7.x recommends 7.4). If you are on Laravel 5, verify you are not relying on 6/7-only helpers.
2. Read the package's composer.json, specifically the illuminate/* and php constraints. A multi-version release usually ships union constraints (^5.5|^6.0|^7.0) with orchestra/testbench branches per version — that file tells you what the maintainer actually tests.
3. Locate the service provider (typically src/*ServiceProvider.php). This is where package config, bindings, and any version-conditional register()/boot() logic lives. On 1.1.0 this is the most likely place for version_compare or method_exists shims.
4. Publish config and review it: php artisan vendor:publish --provider="Vendor\\Package\\PackageServiceProvider". Diff the published file against the package's source copy so future upgrades do not silently overwrite your tuning.
5. Run the first use case: the package's README quickstart, executed against your lowest supported version if you maintain a multi-version codebase. If it works on 5.x it will almost certainly work on 6/7; the reverse is not true.

If you are building or maintaining an application that must span these versions (common for agencies with several long-lived client apps), treat 1.1.0 as the release that lets you share one dependency across your whole portfolio — and set up CI accordingly before you rely on it.

Implementation Patterns

Pin per application, not per machine. Use explicit constraints in each app's composer.json rather than a global resolution:

"require": {
    "php": "^7.2",
    "laravel/framework": "^6.0",
    "vendor/package": "^1.1"
}

Then composer update vendor/package --with-dependencies in one app at a time. Avoid composer update wholesale when you span 5/6/7, or you will resolve different transitive versions per project and lose reproducibility.

Abstract framework-version differences at the edges. Laravel 5 → 6 introduced semantic versioning and split several components; 6 → 7 changed route caching behaviour, getRouteKeyName defaults, and session/queue internals. Keep those differences in your own service layer rather than in package usage:

// app/Support/Laravel.php
class Laravel
{
    public static function isV5(): bool
    {
        return version_compare(app()->version(), '6.0.0', '<');
    }
}

Lockfile discipline across a version matrix. If you maintain one package consumer per Laravel version, commit composer.lock for each and treat them as separate artifacts. This is the single highest-value habit when a package claims 5/6/7 support — it makes "works on my machine" impossible to hide.

Container binding over static calls. The package's facade (if any) is convenient in controllers but awkward in queued jobs and Artisan commands that boot before the app is fully resolved. Bind the underlying class in a provider and inject it:

public function register()
{
    $this->app->singleton(PackageClient::class, function ($app) {
        return new PackageClient($app['config']['package']);
    });
}

Test against the real matrix. With orchestra/testbench, run separate CI jobs per framework version:

strategy:
  matrix:
    laravel: [5.8, 6.20, 7.30]
    php: [7.2, 7.4]
    exclude:
      - laravel: 5.8
        php: 7.4

This is the pattern the 1.1.0 change implicitly asks you to adopt — the release claims support, but only your matrix proves it for your usage.

Upgrade path pattern. For an app moving 5 → 6 → 7, upgrade the package to ^1.1 after the framework bump and after laravel-shift-style automated fixes, then re-run the package's own test suite as a smoke test before your application suite. If the package ships tests, run them from vendor/ via a thin testbench harness; it is the fastest compatibility oracle you have.

Gotchas and Tips

• "Supports 5, 6, 7" is a claim, not a guarantee. The release note is a single sentence with no changelog detail. Check the package's CI badge and the actual composer.json constraints before believing it, and check whether all three versions are exercised in CI or only the newest.
• Laravel 5 is past end-of-life (5.8 security support ended in 2019). Supporting it costs PHP version range, which costs type declarations and modern syntax throughout the package. If you are on 6 or 7, watch for @suppress-style compromises — missing return types, array instead of typed properties — that exist purely for 5.x compatibility.
• PHP version collisions. Laravel 5.5+ and 6/7 need different PHP floors; if your app pins PHP 7.4 you cannot install a Laravel 5.7 dependency set cleanly. Resolve with composer why-not laravel/framework 5.7 rather than guessing.
• Facade caching. php artisan config:cache and route:cache behave differently across these versions. Clear caches (php artisan optimize:clear on 6/7; config:clear + route:clear on 5.x) after deploying a package upgrade before concluding the upgrade broke something.
• Silent config drift on upgrade. vendor:publish will not overwrite existing config by default; new keys introduced in 1.1.0 will be null in your app until you re-publish with --force into a scratch directory and diff. Do that diff, then merge by hand.
• Debugging path. If something fails only on one framework version, reproduce with the package's own test suite for that version first — that separates "package bug" from "your integration bug" in minutes. Failing that, Log::debug() inside the service provider's boot() to confirm it registers at all; providers can no-op silently on 5.x when they rely on 6/7-only methods.
• Extension points to prefer. Config-driven override (custom class via a config key) survives package upgrades better than subclassing internals. If the package offers neither, wrap it in your own thin adapter — you will need that seam the moment 2.0 drops Laravel 5 support.
• Watch for an imminent major. Packages that add old-version support in a minor often remove it in the next major. Pin to ^1.1 rather than *, and read the 2.0 changelog early so that an eventual drop of Laravel 5 does not force an emergency rewrite.