- Can I install nanofelis/json-rpc-bundle directly in a Laravel application?
- No. The package is a Symfony bundle (NanofelisJsonRpcBundle) whose integration surface is the Symfony Bundle system: a DI Extension, compiler passes, tagged services, container-compile-time service locators, and Symfony routing and HttpKernel hooks. Laravel has no equivalent for the pieces version 6.0.0 leans into hardest, and that release actually moves further into Symfony-specific machinery rather than away from it. The realistic option for Laravel is an extraction spike: pull out the JSON-RPC 2.0 semantics core (request parsing, method dispatch, batch assembly, error-code mapping) and drive it from your own Laravel controller or route.
- Does this package ship a Laravel service provider or facade?
- There is no Laravel service provider, facade, config publishing, or route macro in this package — it is Symfony-only. Configuration lives in native Symfony bundle configuration (YAML/PHP config under the bundle's alias) and RPC methods are registered by tagging services, typically with the #[JsonRpcService] attribute. To use it under Laravel you would have to write the equivalent wiring yourself: bind your handler classes in Laravel's container and dispatch to them from a controller.
- What PHP version does version 6.0.0 require?
- PHP 8.4 or higher is a hard floor in 6.0.0, and it is a new gating constraint introduced by that release. If your target runtime is PHP 8.2 or 8.3, Composer will refuse to install the package at all, which means your evaluation degrades to reading source and docs on GitHub instead of running the test suite. Check your deployment image and CI matrix before planning any spike.
- Which Symfony versions are supported, and does that help with Laravel compatibility?
- Version 6.0.0 supports Symfony 6.4, 7, and 8, and drops Symfony 5 — a wider constraint range that modestly reduces Composer conflict risk against the Symfony components Laravel pins. That reduced conflict risk does not make it Laravel-compatible, though; passing Composer resolution is not the same as having a working integration layer. Treat the wider constraint as a small convenience, not as evidence the bundle can run inside a Laravel app.
- What changed in version 6.0.0 compared with 5.x?
- 6.0.0 is a coordinated breaking release: the RpcBeforeMethodEvent and the nanofelis_json_rpc.before_method listener were removed in favour of kernel.controller_arguments, service keys are now resolved at build time via a compiler pass and service locator, duplicate #[JsonRpcService] keys are detected at container build time, and #[JsonRpcService] autoconfiguration was added. It also ships a published migration guide and a full changelog. Almost all of those changes are wiring-layer improvements with no Laravel analogue, so they carry little portability value for a Laravel port.
- Was there a security vulnerability in 5.x where __construct could be called as an RPC method?
- Yes. In 5.x, the #[JsonRpcService] attribute exposed __construct on tagged services, so a caller could re-invoke the constructor on the container-shared instance and overwrite injected dependencies for the rest of the request — or for the worker process under FrankenPHP or RoadRunner. That is a serious bug class. 6.0.0 fixes it with an allowlist of public, non-magic, non-abstract methods, so anything else answers -32601; the fix is the correct one and confirms the project responds to real reports.
- How does it handle batch requests and what is max_batch_size for?
- Batch requests are parsed and assembled by the JSON-RPC semantics core, and 6.0.0 tightens the spec edges: malformed batch entries no longer discard sibling calls, an empty batch [] answers -32600, non-conforming ids such as floats or arrays answer -32600 instead of throwing a TypeError or a 500, and a missing jsonrpc key no longer emits an undefined-key warning on the way to -32600. The new max_batch_size option defaults to 100, and setting it to 0 disables the limit. It directly addresses batch amplification, which is the hardest operational problem with this protocol shape, and it is one of the few features genuinely worth carrying over into a Laravel implementation.
- How do you install and configure it in a Symfony app?
- Install it with Composer, register NanofelisJsonRpcBundle in config/bundles.php, configure the endpoint and method mappings in the bundle's config, and annotate your RPC service classes with #[JsonRpcService]. In 6.0.0, autoconfiguration and build-time service-key resolution mean you no longer need to hand-wire every tagged service. None of this translates to Laravel, so a Laravel port means reimplementing the endpoint, routing, and dispatch layer around the extracted protocol classes.
- How are exceptions mapped to JSON-RPC error codes?
- The bundle includes error and exception mapping, translating thrown exceptions from your services into structured JSON-RPC 2.0 error responses rather than raw 500s. That mapping layer is part of the portable semantics core, along with parsing, dispatch, and batch assembly. During an extraction spike, confirm the mapper does not type-hint HttpKernel classes or resolve handlers through the Symfony container before you copy it.
- Is the project actively maintained, and how should a Laravel team evaluate it?
- The maintenance signal is stronger than it was: a migration guide, a full changelog, a coordinated breaking release, and a security fix shipped together, and a real vulnerability was found and closed. One metadata anomaly remains — a release date that cannot be reconciled from the available data — so verify tags, commits, and CI activity yourself. For Laravel, scope the evaluation as a one-to-two day extraction spike: locate the parser, dispatcher, and error mapper, confirm they are free of HttpKernel coupling, and ignore the bundle wiring above them entirely.