Laravel Blade Directives Laravel Package

Getting Started

This release (1.14.0) is a compatibility release only — the sole change is a composer.json constraint update for Laravel 10. There are no new APIs, config keys, or behaviours to learn, so "getting started" here means getting your install onto 1.14.0 and confirming nothing else moved.

1. Check PHP first. Laravel 10 requires PHP ^8.1. If your app is still on PHP 8.0, no amount of Composer juggling will install this. Verify with php -v and your CI image tag before touching composer.json.

2. Read the diff, not just the note. "Update composer for Laravel 10" can mean either of two very different things:

   • Widened: "illuminate/*": "^9.0|^10.0" → L9 is still supported, low risk.
   • Narrowed: "illuminate/*": "^10.0" → L9 support dropped, and anything else in your stack pinned to L9 breaks.

   Run composer diff (or fetch the GitHub compare view) for 1.13.x...1.14.0 and look at composer.json before you plan the upgrade.

3. Require the minimum version explicitly. Don't rely on ^1.0 resolving upward:

   composer require vendor/package:"^1.14" --with-all-dependencies
   

4. Where to look first in the package: the require/require-dev block in its composer.json (for the actual framework constraints and PHP floor), then CHANGELOG.md to confirm 1.14.0 has no code changes, then the service provider to confirm package auto-discovery still registers cleanly.

5. First use case: this is an upgrade use case, not a greenfield one. Take an existing L9 app + this package, bump PHP, bump the package, run the test suite. If the suite is green, you're done — there is nothing new to adopt.

Implementation Patterns

Because the release is constraint-only, the useful day-to-day patterns are about version hygiene across environments, not about calling new features.

Pin the floor, not the ceiling. In composer.json, use a caret constraint that starts at the first Laravel-10-capable release so a fresh composer install on another machine can't silently resolve to an older L9-only version:

"require": {
    "php": "^8.1",
    "vendor/package": "^1.14"
}

Transitional CI matrix. While some services are on L9 and others on L10, test the package against both until the widened/narrowed question above is settled for your app. Once you're fully on L10, collapse to a single job to cut CI time.

Upgrade ordering. Do the framework bump before the package bump, not after. Laravel 10 first, get the app's own tests green, then let this package's constraint resolve. Doing it in the other direction makes it impossible to tell whether a failure came from the framework or the package.

Treat the lockfile as the artefact. composer.lock is what actually ships. After upgrading, commit the lock diff and review it — the interesting part of a constraint-only release is what else got dragged along by the solver.

Dependabot/Renovate config. A patch-level constraint bump should be auto-merged only if you have a test suite that actually exercises the package's integration point (the service provider boot, any published config). If you don't, keep it manual — a broken provider boot in production is a bad way to learn you had no coverage.

Gotchas and Tips

No code change ≠ no risk. The risk in this release is entirely transitive. A widened or narrowed illuminate/* constraint changes what Composer is allowed to install alongside it, which can pull in a different version of a shared dependency. Read the lockfile diff, not just the release note.

Diagnose solver failures with why-not, not guesswork.

composer why-not vendor/package 1.14.0

This tells you exactly which package is holding you back (usually a dev dependency still pinned to L9). --with-all-dependencies is the fix when it's a transitive pin; it is not a fix when the blocker genuinely doesn't support L10 — in that case you're choosing between the blocker and the upgrade.

Don't assume L9 still works. If the constraint was narrowed, the package will still install on an L9 app if an older version satisfies it — but your team may be running different versions in different environments without anyone noticing. Grep the lockfile across services.

A missing CHANGELOG entry is itself information. If 1.14.0 only says "Update composer for Laravel 10" and nothing else, that's the maintainer telling you there's no behavioural delta. Trust it far enough to skip a manual regression pass, but still run the suite.

Framework-level removals are your problem, not the package's. Laravel 10 dropped PHP 8.0 support and removed a set of long-deprecated framework methods. If something breaks after this upgrade and the package's diff is composer.json-only, the cause is almost certainly the framework bump or a third-party dep — work Laravel's own 10.x upgrade guide, not this package's issue tracker.

Maintenance signal. A same-day Laravel 10 constraint bump is a good sign: the maintainer is responsive. Factor that into how much you're willing to build on the package — but it's not a feature release, so don't schedule work around it.

Extension points: none new. No service container bindings, config keys, or events were added in this release. If you were hoping 1.14.0 would unblock a customisation, it didn't — check the roadmap or open an issue.