Laravel Health Env Vars Laravel Package

Getting Started

Version 1.11.0 is a compatibility release, not a feature release. The only changes are added support for Laravel 13 and PHP 8.5. There are no new APIs, no deprecations, and no breaking changes. Practically, this means:

• If you're on Laravel 10/11/12 and PHP 8.2–8.4: nothing changes for you. Upgrade at your normal cadence.
• If you're planning a Laravel 13 or PHP 8.5 upgrade: 1.11.0 is the minimum version you must be on before attempting it. Older releases will not have been tested against those runtimes.

First steps for a developer picking this up:

1. Check your constraints allow it — composer require the package at ^1.11 and confirm composer why-not doesn't complain about your Laravel/PHP version.
2. Publish and review the config (php artisan vendor:publish) before writing any code; the defaults are usually production-sane but the tunables are where most day-to-day behaviour lives.
3. Find the package's service provider and facade (if any) early — that's your map of what's actually bound into the container and what you can swap or mock in tests.
4. Run the package's own test suite against your app's Laravel version if you're on 13, since that's the newly-added support surface.

First use case: wire it into a single feature or command behind a config flag, verify it under your test suite, then broaden usage. Don't adopt it app-wide on the same commit you bump the framework version — you'll have no way to tell which change broke what.

Implementation Patterns

Pin the compatibility matrix deliberately. Because 1.11.0 is purely additive compatibility, the useful pattern is to treat it as the floor of your constraint, not the ceiling:

"require": {
    "php": "^8.2",
    "laravel/framework": "^11.0|^12.0|^13.0",
    "vendor/package": "^1.11"
}

If you support multiple Laravel majors in a shared library, mirror the package's own approach: widen constraints, keep testing each lane in CI rather than assuming forward compatibility.

Upgrade sequencing. When moving an app to Laravel 13 or PHP 8.5, bump this package first in isolation, run the suite, then bump the framework. Two-variable upgrades are the most common source of "which change caused this" debugging sessions.

CI matrix as the integration tip. If you maintain anything downstream, add a Laravel 13 / PHP 8.5 lane now rather than waiting for a user report. The package author has signalled the combination is supported; you're responsible for confirming your own code paths (custom bindings, overridden config, decorated services) behave under it.

Isolation for testing. Resolve the package through the container rather than instantiating directly. That keeps you able to bind a fake in tests and lets you survive constructor signature changes across majors — of which 1.11.0 has none, but future minors might.

Config-driven rollout. Gate adoption behind an environment-driven config value so a feature can be turned off in production without a redeploy if the new framework/runtime combination surfaces something the package's test suite didn't cover.

Gotchas and Tips

• "Adds support" ≠ "requires". 1.11.0 does not force you onto Laravel 13 or PHP 8.5. Don't let a routine composer update drag your framework forward via transitive constraints — check composer update --dry-run output for unexpected framework bumps.
• Composer resolution order matters. If another dependency still caps Laravel at ^12, installing ^1.11 is fine, but you won't be able to move to 13 until every package in the graph has widened. Use composer why-not laravel/framework ^13.0 to find the blockers rather than guessing.
• PHP 8.5 is new — extension and tooling lag is real. Static analysis baselines, PHPUnit/Pest versions, and CI images often trail a PHP minor. If your pipeline fails on 8.5, it's more likely tooling than this package; verify by running the suite on 8.4 first.
• Lock files are the source of truth in CI. After bumping, commit composer.lock so CI and production resolve identically. A compatibility bump that passes locally but resolves differently in CI is almost always a lock-file drift issue.
• No changelog depth to rely on. A release note this terse means the diff is your documentation. If you hit odd behaviour after upgrading, diff the package source between tags rather than searching for release notes — there are no feature-level notes to search for.
• Extension points are unchanged in this release. Any custom bindings, config overrides, or subclassing you've done against 1.10.x should carry over untouched. If something breaks, suspect the framework/runtime change, not this package.
• Debugging tip for the new runtimes: if you see deprecation notices on PHP 8.5 that weren't there on 8.4, capture the full stack trace and confirm whether the package or your own app code is the origin before filing upstream — the package explicitly claims 8.5 support as of this version, so anything traced into it is a legitimate report.
• Don't skip the intermediate majors. Jumping Laravel 11 → 13 in one step with this package is supported on paper, but the package can only guarantee its own behaviour; Laravel's own upgrade guide steps still apply to your app code.