Jsonrpc Laravel Package

Product Decisions This Supports

• API contract strategy: This package ties Laravel services to an OpenRPC/JSON-RPC contract. The v6 shift of summary/description out of package config and "to the openrpc side" is a decision point: your API documentation becomes an external artifact, not a package concern. If you ship public or partner-facing RPC APIs, this clarifies ownership of the contract.
• Schema/depth roadmap: Nested objects in API parameters and ApiValidation on object fields unlock genuinely typed, deep request payloads. This is the headline feature for PMs — it moves the package from flat-parameter RPC toward schema-driven RPC, enabling richer product surface (composite resources, nested filters, structured writes) without hand-rolled validation.
• Build vs. buy: Validation rework plus attribute-based method marking means less bespoke validation glue in your app. If you were maintaining custom casters or a homegrown validation layer, v6 removes that maintenance burden — but also removes your escape hatches.
• Migration planning is a product decision, not just a technical one: This is a breaking release. Every "removed from config" item (allowParentMethods, customCasters), the dropped JsonRpcController trait, the mandatory ApiMethod attribute, and dropped Laravel 10 / PHP 8.2 support are gated changes. Roadmap impact: a mandatory upgrade sprint, potential service compatibility matrix narrowing, and coordinate with any team still on Laravel 10.
• Runtime support window is widening, not narrowing (beta.2): 6.0.0-beta.2 adds PHP 8.5 support. Practically, this means the v6 line is tracking the newest PHP runtime rather than pinning to a floor — good news for platform-roadmap sequencing, since an eventual org-wide PHP 8.4/8.5 upgrade won't strand your RPC layer. It does not relax the lower bound: PHP 8.2 and Laravel 10 remain unsupported. Treat this as a forward-compatibility signal, not a reason to accelerate adoption.
• Beta status drives release timing: 6.0.0-beta.1 and 6.0.0-beta.2 should not anchor a customer-facing commitment. Beta.2 is a one-line compatibility patch — it signals active maintenance, not feature maturity. Treat the line as a spike/evaluation input, not a GA plan.

When to Consider This Package

Consider it when:

• You expose a Laravel backend as a JSON-RPC API and want attributes, validation, and OpenRPC-documented contracts without writing a transport layer.
• You need nested/structured request parameters with field-level validation — v6 is materially better here than prior versions.
• You are on Laravel 11+ and PHP 8.3+ (v6 requires it — verify exact floors against the package's composer constraints). PHP 8.5 is now explicitly supported as of beta.2, so teams already on or planning PHP 8.4/8.5 are not blocked on the upper end.
• You are greenfield on the RPC surface and can adopt ApiMethod attributes from day one, so the breaking changes cost you nothing.

Look elsewhere or hold when:

• You are on Laravel 10 or PHP 8.2 — v6 is a hard wall; either stay on v5.x or budget an upgrade of the host application first. (The PHP 8.5 addition does not change this; the lower bound is unchanged.)
• You depend on customCasters for custom type serialization or on allowParentMethods for controller inheritance. Both are gone with no stated replacement — this is the single biggest adoption risk and needs an explicit mitigation plan (fork, adapter, or redesign).
• You rely on the JsonRpcController trait. Deprecated and now removed; audit for usage before committing.
• You need stable, GA-grade dependencies — a beta is not a release commitment for production roadmaps. Beta.2 is a compatibility patch, not a stabilization milestone; no signal yet on when (or whether) the removals get migration paths.
• Your API docs need to live in-repo: config-level summary/description are gone, so documentation now depends on an external OpenRPC source of truth you must own and keep in sync.

How to Pitch It (Stakeholders)

To executives: The package's new major version modernizes our RPC layer — better-typed API inputs, validation handled by the framework instead of custom code, and a cleaner separation where API documentation lives in the API contract rather than in configuration. It reduces long-term maintenance surface, and the latest beta adds PHP 8.5 support so the package keeps pace with our runtime upgrade path rather than becoming a blocker. The trade-off is a breaking upgrade: it requires Laravel 11+/PHP 8.3+, forces every API method to be explicitly annotated, and drops two customization hooks (customCasters, allowParentMethods) plus a deprecated controller trait. It is still a beta — the most recent release is a small compatibility patch, not a stability signal — so we should evaluate now and schedule the migration rather than rush it into production.

To engineering: This is a deliberate breaking release that simplifies the package at the cost of flexibility. All API methods must carry #[ApiMethod]; JsonRpcController, customCasters, allowParentMethods, and config-level summary/description are removed; Laravel 10 and PHP 8.2 are unsupported. PHP 8.5 is now supported (beta.2), so the upper end of our runtime matrix is fine — the constraint that matters is still the floor. In exchange we get nested objects in parameters, ApiValidation on object fields, and a reworked validation pipeline. Action items before adoption: (1) inventory every use of customCasters, allowParentMethods, and the controller trait; (2) confirm our Laravel/PHP versions against the v6 floor (8.3+) rather than the ceiling; (3) prototype the nested-object and field-level validation paths against a representative endpoint; (4) define where the OpenRPC document is authored and how it stays in sync with code.