Laravel Encryptenv Laravel Package

Getting Started

Release 1.1.0 is a compatibility release, not a feature release — the only documented change is a composer.json dependency update to allow Laravel 11. Treat your first hour as "confirm it installs and boots," not "learn new APIs."

1. Check the constraint before you upgrade. Open the package's composer.json and look at the illuminate/* / laravel/framework requirement. If it now reads ^10.0|^11.0 you can upgrade in place on an existing Laravel 10 app. If it reads ^11.0 only, plan the Laravel 11 upgrade first (PHP 8.2+, new skeleton, bootstrap/app.php).
2. Install:

   composer require vendor/package:^1.1
   

3. Look first at, in this order:
   • composer.json — constraints and any bumped transitive dependencies.
   • The service provider (src/*ServiceProvider.php) — this tells you what is bound, what is publishable, and whether anything is deferred.
   • config/*.php inside the package — the real list of knobs.
   • README / CHANGELOG for 1.1.0 — confirm nothing beyond the dependency bump is listed.
4. First use case: confirm the container binding resolves and the package's primary entry point (facade, helper, Artisan command, middleware, or route macro — whichever the provider exposes) works end to end:

   php artisan about          # provider listed?
   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
   php artisan config:clear
   

   Then exercise the single most common call the README shows, inside php artisan tinker, before wiring it into application code.

Implementation Patterns

Resolve from the container, never new. A dependency-bump release is exactly when constructor signatures are most likely to have shifted invisibly. Always go through the facade or app(...) so a binding change doesn't break you.

Keep a thin adapter. Wrap the package behind one small class of your own (App\Support\XxxGateway) that delegates to it. When the next release changes a method or a config key, you edit one file instead of grepping the codebase. This costs 20 minutes and pays for itself at the next major.

Publish and commit config. Under Laravel 10 you often had a config/ directory full of files; Laravel 11's slim skeleton does not. If the package ships a config file, publish it, commit it, and drive values from env() so config caching behaves predictably.

Provider registration differs by version.

• Laravel 10: config/app.php → providers array (if not auto-discovered).
• Laravel 11: bootstrap/providers.php.

Auto-discovery usually handles this, but if the package isn't discovered, that file is where you add it manually.

Run a two-version CI matrix during the transition. If the package supports both 10 and 11, test both:

php: [8.2, 8.3]
laravel: [10.*, 11.*]

This is the cheapest way to catch a dependency constraint that silently resolves differently per framework version.

Testing. If the package provides fakes or a testing trait, use them; otherwise bind a mock into the container in setUp():

$this->app->instance(PackageContract::class, $fake);

Avoid asserting against vendor internals — assert against your adapter's behaviour.

Staged rollout. Because the change surface is "dependencies only," deploy to staging, run the full suite plus a smoke test of the package's main path, then ship. Don't bundle this upgrade with a feature branch.

Gotchas and Tips

• A "dependencies only" release is not automatically a no-op. Widening a framework constraint frequently pulls in newer transitive packages (test utilities, HTTP clients, date libraries). Run composer update --dry-run first and read the diff; composer why any package that moved unexpectedly.
• Carbon 3 in Laravel 11 changes some date arithmetic and comparison behaviour. If the package touches dates, re-run anything that asserts on formatted output or diff calculations.
• PHP 8.2 minimum for Laravel 11. If your CI image or Docker base is still 8.1, the install will fail with a confusing constraint error rather than a clear version message.
• bootstrap/cache/packages.php goes stale. If the provider "isn't there" after upgrading, run php artisan package:discover and, if that fails, delete bootstrap/cache/packages.php and services.php.
• Config caching silently ignores env() calls outside config files. After editing a published config, always php artisan config:clear locally and re-cache in production via your deploy script.
• Pin deliberately when you can't move. If you're staying on Laravel 10 and 1.1.0 requires 11, constrain to ^1.0 in composer.json so a routine composer update doesn't drag you into a framework upgrade.
• No deprecations or breaking changes are documented for 1.1.0. That's a green flag but also a reminder: the release notes are terse. Check the diff of the published composer.json against your installed version if you want certainty about what actually moved.
• Extension points to know before you need them: container bindings in the service provider (swap implementations), published config (behaviour without forking), and any events the package dispatches (hook in without subclassing). If the README doesn't document events, grep -r "dispatch(" src/ in vendor/ is the fastest way to find them.
• Keep an upgrade note. Record the resolved version, the Laravel/PHP pair you validated against, and the one smoke-test command that proves it works. The next dependency-bump release will land with equally thin notes, and this note is what makes it a five-minute job.