Symfony Jsonrpc Http Server Doc Laravel Package

Technical Evaluation

Architecture fit. yoanm/symfony-jsonrpc-http-server-doc is a Symfony bundle that introspects a JSON-RPC HTTP server configuration and emits API documentation. It is built around Symfony's DI container, bundle extension/config tree, and routing — none of which are first-class citizens in Laravel. Its fit for a Laravel codebase is therefore indirect at best: it is usable only where the JSON-RPC server itself is Symfony-based, or where we are willing to stand up a parallel Symfony kernel solely for doc generation. It is not a Laravel package in any meaningful sense, and it will not participate in Laravel's package discovery.

Integration feasibility. The v2.0.2 release changes the Composer type from (presumably) library to symfony-bundle (PR #36). This is metadata only — no code, API, or behavioural change. Practical consequences:

• For Symfony Flex consumers, type: symfony-bundle is the signal used for bundle auto-registration where a recipe exists; it improves install ergonomics there.
• For Laravel consumers, type has no runtime effect. Laravel's auto-discovery reads extra.laravel.providers, not type. The package remains installable as a normal dependency via composer require.
• No new transitive dependencies, no autoload changes, no breaking changes. Upgrade from v2.0.1 is a lockfile-only diff.

Technical risk. Low for the release itself; moderate-to-high for the integration premise. The real risk is not v2.0.2 but the assumption that a Symfony bundle belongs in a Laravel service. Introducing Symfony's HttpKernel/DI alongside Laravel's container creates dual-container ambiguity, duplicated autowiring semantics, and a second configuration surface to secure and document.

Key questions.

1. Is our JSON-RPC server actually Symfony-based, or are we trying to document a Laravel-hosted JSON-RPC endpoint? If the latter, this package is the wrong tool.
2. If we run a sidecar Symfony app purely for documentation, who owns its deployment, config, and version pinning?
3. Does the doc output format (OpenAPI/HTML/JSON) meet our API portal requirements, or will we need a transformation layer anyway?
4. Is there a Laravel-native alternative (e.g. Scribe, Scramble, or a hand-rolled introspector) that avoids the dual-framework tax?

Verdict on v2.0.2. Packaging hygiene, not a functional change. Nothing here changes the decision calculus; it slightly improves the Symfony-side story and is neutral for Laravel.

Integration Approach

Stack fit. Poor-to-conditional. The package assumes Symfony bundle conventions: a DependencyInjection/*Extension class, a Configuration tree, and tag-based service discovery. Laravel offers none of these. Any integration must either (a) colocate a minimal Symfony kernel, or (b) treat the package as a CLI-time tool invoked against a Symfony-config-shaped input rather than as a runtime dependency of the Laravel app.

Migration path. Recommended sequencing:

1. Spike (1–2 days): stand the bundle up against the existing JSON-RPC server config in an isolated Symfony skeleton and produce a sample doc artifact. Do not touch the Laravel application.
2. Decision gate: confirm the generated output meets the API portal spec. If not, stop and evaluate Laravel-native generators.
3. Isolate: if proceeding, run doc generation as a build/CI step or sidecar container, never as a runtime dependency loaded into the Laravel request lifecycle.
4. Publish: emit artifacts into the existing docs pipeline (CI → static hosting) so the Laravel app has zero awareness of the tool.

Compatibility. PHP version and Symfony component constraints must be reconciled against the Laravel app's own Symfony-component pins (Laravel pulls in symfony/console, symfony/http-foundation, symfony/process, etc.). Composer will resolve these jointly, and a Symfony major-version conflict is the most likely install-time failure. Because both stacks share the symfony/* namespace, constraint drift is subtle and worth checking explicitly rather than assuming.

Sequencing relative to the release. No action is gated on v2.0.2. Pin to ^2.0 and let the type change land passively; there is no reason to schedule an upgrade window for a metadata diff.

Operational Impact

Maintenance. Two dependency graphs to keep current — Laravel's and the doc tool's Symfony stack — with an overlapping symfony/* surface. That is a recurring, low-volume but non-zero maintenance tax borne entirely for a documentation feature. Weigh it against the cost of a Laravel-native generator.

Support. Upstream is a single-maintainer project (@yoanm) with a small contributor base. Bus factor is the dominant support risk, not the release cadence. The v2.0.2 changelog is a one-line metadata PR, which is a reasonable signal of project health (maintained, if quiet) but also of narrow scope. Expect to self-support integration issues, particularly any Laravel/Symfony interop problems, since they fall outside the maintainer's supported surface.

Scaling. Documentation generation is an offline, batch concern — it scales with CI minutes, not with request volume. No runtime scaling implications. If run as a sidecar, its resource footprint is trivial and independently scalable.

Failure modes.

• Install-time: Composer constraint conflict between the bundle's Symfony requirements and Laravel's pinned Symfony components. Detected at composer update; blocks the build.
• Config drift: the JSON-RPC server definition changes but the doc-generation config is not updated in lockstep, producing stale or partial docs. Silent failure — the worst kind here.
• Dual-container confusion: if loaded at runtime, services registered in one container are invisible to the other, yielding confusing "service not found" errors.
• Abandonment: upstream goes dormant; the pinned Symfony version ages out of support and eventually blocks our own framework upgrades.

Ramp-up. Moderate. A Laravel developer unfamiliar with Symfony bundle conventions will need to learn the extension/Configuration pattern and Flex semantics to debug even simple issues. Budget roughly half a day of onboarding per engineer who touches this, plus the spike above. The v2.0.2 type change marginally reduces ramp-up on the Symfony side (bundle auto-registration) and does nothing on the Laravel side.

Recommendation. Do not adopt as a runtime Laravel dependency. Evaluate it as an isolated CI-time documentation generator only if the JSON-RPC server is genuinely Symfony-based; otherwise pursue a Laravel-native generator. v2.0.2 requires no action.