Laravel Json Ld Laravel Package

Technical Evaluation

Architecture fit

No prior assessment exists for this package, so v2.2.0 establishes the baseline. The release notes describe a platform-support release only: no API, config, schema, or behavioural changes are declared. For a TPM this reads as a compatibility-metadata change rather than a functional one, which is good news for integration cost but bad news for version-management hygiene — the package's supported footprint has narrowed in a patch/minor slot.

The net supported matrix after v2.2.0 is approximately:

This is a de facto major release shipped as 2.2.0. Dropping PHP 8.1/8.2 and Laravel 9 changes the install contract for a meaningful share of any established estate. Treat it internally as a breaking change for planning purposes, regardless of the version number.

Integration feasibility

Feasible but conditional on the host application's own upgrade state. The package cannot be adopted in isolation: it is gated behind whatever PHP and Laravel versions the consuming service already runs. A team on Laravel 9 / PHP 8.1 must complete two framework hops (9 → 10 → 11/12) and at least two PHP hops before this package version is even installable. Teams already on Laravel 11 / PHP 8.3 get this for free.

Two behaviours to verify before committing:

1. Hard vs. soft enforcement. If the drop is expressed in composer.json require, Composer will refuse installation and resolve to the newest compatible 2.1.x — safe but silent. If it is only reflected in CI matrices without constraint changes, consumers can install an untested combination. Confirm which.
2. Backport policy for 2.1.x. The release notes give no statement on security patching for the now-unsupported line. This is the single most important open item.

Technical risk

• Silent version pinning (high). On PHP 8.1/8.2 stacks, composer update will quietly hold at 2.1.x. Teams may believe they are current. Without an inventory check this is invisible.
• Semver erosion (medium). Platform drops in a minor release weaken the value of the version constraint as a safety signal. Any automated dependency policy keyed on "minor = safe" must be adjusted for this package.
• Laravel 13 / PHP 8.5 maturity (medium). Both are forward-looking targets. Confirm whether support was validated against GA or release candidates, and whether the maintainer commits to stability of that support.
• Ecosystem lag (medium). Other packages in the dependency graph (auth, admin panels, testing helpers, static analysis) may not yet support Laravel 12/13, creating resolution deadlocks at the app level.
• Support fragmentation (medium). A widening spread of installed versions across services increases the cost of any future coordinated upgrade.

Key questions

1. Is 2.1.x still receiving security fixes, and until when? What is the published end-of-support date?
2. Is the PHP/Laravel drop enforced via composer.json require, or advisory only?
3. Are the public API, config keys, and published assets unchanged in 2.2.0? Confirm no undocumented behaviour changes.
4. Was Laravel 13 / PHP 8.5 support tested against stable releases or pre-release builds?
5. Is a 3.0 planned that removes Laravel 10 — and on what timeline?
6. Why was a platform drop not staged with a deprecation window in a prior release?

Integration Approach

Stack fit

The package remains a standard Laravel library dependency — no runtime services, no infrastructure footprint. Fit is determined entirely by the host application's platform version. Segment the estate into three buckets:

• Green: Laravel 11+, PHP 8.3+ — adopt 2.2.0 immediately, no work.
• Amber: Laravel 10, PHP 8.3 — adoptable now; note Laravel 10 is near end of life and plan the framework hop.
• Red: Laravel 9 or PHP 8.1/8.2 — blocked. Package upgrade is a downstream consequence of a platform upgrade, not an independent workstream.

Migration path

1. Inventory first. Produce a service-by-service matrix of current PHP and Laravel versions and currently resolved package version. This is the artefact that makes the rest of the plan real; without it the "silent pinning" risk is unmanaged.
2. Pin deliberately. For Red services, add an explicit upper bound or documented hold so the pinned 2.1.x state is a known decision rather than an accident. Raise a tracked risk for each.
3. Upgrade PHP before Laravel. PHP 8.3 is the safe common floor; target 8.4 where the host and extensions allow. PHP 8.5 should be piloted, not adopted as a baseline.
4. Upgrade Laravel in single hops. 9 → 10 → 11 → 12, validating after each. Do not attempt a multi-hop jump in one change.
5. Adopt 2.2.0 last, as a trivial version bump once the platform prerequisites are satisfied.
6. Re-baseline after adoption. Record the new matrix in the service catalogue so the next platform drop is anticipated rather than discovered.

Compatibility

• Verify PHP extension availability on host images and managed platforms before targeting 8.4/8.5.
• Audit the full transitive dependency set for Laravel 12/13 readiness — this, not the package itself, is where the schedule risk sits.
• Confirm static analysis, code style, and test tooling versions are compatible with the target PHP version; these commonly break before application code does.

Sequencing

Phase 1 (week 1–2): inventory, publish the version matrix, obtain the maintainer's 2.1.x support statement. Phase 2 (weeks 2–8): platform upgrades for Amber and Red services, prioritised by exposure. Phase 3 (ongoing): adopt 2.2.0 as services land, then lock in a recurring dependency-review checkpoint so future platform drops are caught at release rather than at audit.

Operational Impact

Maintenance

The maintainer's test matrix has narrowed, which reduces their cost and should improve confidence in what is supported. The cost transfers to consumers, who now own a fragmented installed base across 2.1.x and 2.2.x. Establishing a single supported version in production is worth real effort — every additional live version multiplies upgrade and incident-diagnosis work later.

Support

The absence of a published end-of-support commitment for 2.1.x is the primary operational gap in this release. Request one and record it as a tracked dependency risk with an owner and review date. If none is forthcoming, plan to eliminate 2.1.x from production on a self-imposed deadline rather than an indefinite hold.

Scaling

No runtime, throughput, or resource implications — this is a compile-time dependency contract. "Scaling" here means scaling governance: as the number of services grows, the cost of a per-service version audit grows with it. Automate the inventory (a scheduled composer show sweep or dependency dashboard) before the estate is large enough to make manual tracking untenable.

Failure modes

Ramp-up

Low. No new APIs or configuration to learn; developer-facing effort is limited to dependency and platform upgrades teams were already facing. The real ramp-up is organisational: getting dependency policy to treat platform-support drops in minor versions as reviewable events, and getting the maintainer's support commitments documented.

TPM recommendation: Adopt v2.2.0 as the target state, but do not treat it as an isolated upgrade. It is a forcing function for a platform-version programme that a portion of the estate needs regardless. Fund Phase 1 (inventory plus the maintainer support question) immediately — it is cheap and it converts an invisible risk into a scheduled one. Gate the rest on the resulting matrix.