Symfony Jsonrpc Http Server Doc Laravel Package

Getting Started

This package is a Symfony bundle (yoanm/symfony-jsonrpc-http-server-doc), not a Laravel package. Before you write any Laravel code, internalise that: there is no service provider, no facade, no config file published by vendor:publish, and Laravel's package discovery (extra.laravel.providers) does not apply. v2.0.2 changes the Composer type from library to symfony-bundle, which is a metadata change for Symfony Flex — it does not add Laravel support and does not change runtime behaviour.

Where to look first:

1. composer show yoanm/symfony-jsonrpc-http-server-doc — confirm the version and that type now reports symfony-bundle.
2. vendor/yoanm/symfony-jsonrpc-http-server-doc/ — read composer.json (note the symfony/* and yoanm/symfony-jsonrpc-http-server requirements) and the bundle class / DependencyInjection/Configuration.php for the config tree.
3. Resources/config/ — this is the real contract: service IDs, aliases, and the tagged services you can override.

First use case: you have a JSON-RPC HTTP server (built with yoanm/symfony-jsonrpc-http-server) and you want a generated spec (Swagger/OpenAPI) served from an endpoint or dumped to a file for Swagger UI / Stoplight / contract tests. In a Symfony app that's "enable the bundle, configure the server, hit the doc route."

In a Laravel app, the realistic first use case is narrower: consume the doc-building classes directly (or vendor/port them) rather than treating this as an installable Laravel feature. Confirm you actually need it before pulling a second DI container's worth of Symfony components into your app.

Implementation Patterns

Pattern 1 — Symfony app (the intended path). Even with type: symfony-bundle, auto-registration only happens if a Flex recipe exists; otherwise register it manually in config/bundles.php, add config under config/packages/, and point the doc route at your JSON-RPC server. Treat type as capability signalling, not as "it configures itself."

Pattern 2 — Laravel app, classes only. Skip the bundle. In a service provider, bind the doc builder / response factory interfaces the package exposes to their concrete implementations, feeding them the JSON-RPC method definitions you already have. Because the package returns Symfony HttpFoundation responses, and Illuminate\Http\Response extends Symfony\Component\HttpFoundation\Response, a controller can often return the factory's response directly — verify content type and status handling before relying on it.

Pattern 3 — build-time artifact, framework-agnostic. The most portable use: generate the spec in CI (a console command or a small script), commit or publish openapi.json, and let Swagger UI / Redoc / Stoplight render it. This sidesteps the container-integration problem entirely and is what most Laravel teams should do if they need this package at all.

Pattern 4 — contract tests. Snapshot the generated doc in a PHPUnit/Pest test and assert on method names, parameter schemas, and descriptions. This catches the common regression where a new RPC method is added but never documented.

Integration tip: if you're in a hybrid repo (Symfony service in a monorepo, Laravel app consuming it over HTTP), keep the doc generation on the Symfony side and let Laravel fetch GET /doc — don't duplicate the dependency tree.

Gotchas and Tips

• The v2.0.2 change is a no-op for Laravel. type: symfony-bundle affects Flex/Composer tooling and package classification; Laravel auto-discovery is driven by extra.laravel, which this package does not set. Nothing breaks, nothing gets easier.
• type: symfony-bundle ≠ auto-enabled. Without an accompanying Flex recipe, you still register the bundle in config/bundles.php. Don't assume composer require wires it up.
• Dependency conflicts are the likely failure mode. This pulls symfony/* components and the JSON-RPC server package. In a Laravel app already pinned to particular Symfony versions, composer why-not yoanm/symfony-jsonrpc-http-server-doc is your first debugging step.
• No vendor:publish, no facades. If a tutorial tells you to publish config or use a facade, it isn't about this package.
• Stale docs after config changes. Doc output is derived from configuration and tagged method definitions; clear the container cache (Symfony) or your own config cache (Laravel) after changing either, or you'll debug a phantom schema.
• Content negotiation lives in the response factory. If you need JSON vs YAML, or a different spec version, that's the extension point to swap — not the route.
• Override by alias. The supported extension point for custom doc-building logic is replacing the package's service with your own implementation via a container alias (Symfony) or a container binding (Laravel), not editing vendor code.
• Pin to ^2.0 and read the diff between minors. v2.0.2 is metadata-only, but the 2.x line requires modern PHP/Symfony — check composer.json constraints against your runtime before assuming compatibility.