Jsonrpc Params Symfony Constraint Doc Sdk Laravel Package

Product Decisions This Supports

• API documentation strategy (single source of truth). The package derives JSON-RPC method parameter docs directly from Symfony Validator constraints on DTOs, so the contract published to consumers tracks the actual validation rules instead of a hand-maintained wiki/OpenAPI file. This is the core decision it informs: "do we document the API by hand, or generate it from code?"
• Developer experience / SDK roadmap. Accurate machine-readable parameter docs are the prerequisite for generating client SDKs, Postman collections, and typed stubs for internal consumers. If SDK generation is on the roadmap, this is a cheap enabler.
• Build vs. buy (small utility). The surface area is narrow — constraint metadata in, doc structure out. Estimated in-house cost is days, not weeks. The decision is therefore less "can we build it" and more "do we want to own a doc-format renderer that must track Symfony Validator changes."
• Contract-drift reduction as a support-cost lever. For teams fielding integration questions, keeping parameter docs synchronized with validation reduces a recurring class of support tickets ("why did my call fail validation when the docs said X?").
• Fit with the existing JSON-RPC stack. Adoption makes sense primarily as a component of the yoanm JSON-RPC ecosystem; it is a composable piece, not a standalone platform decision.

When to Consider This Package

Consider it when all of the following hold:

• You are already running a JSON-RPC server (particularly yoanm/php-jsonrpc-server) and need published, machine-readable parameter documentation.
• Your request DTOs already carry Symfony Validator constraints as attributes — i.e., you have a genuine Symfony Validator layer, not just illuminate/validation rules.
• You want doc generation wired into CI so docs cannot silently drift from code.
• You accept a zero-adoption dependency (0 stars, 0 dependents) as a vendored/forkable utility rather than a community-supported library.

Look elsewhere when:

• The codebase is Laravel-idiomatic. Laravel's default validation layer (illuminate/validation, FormRequests, rule arrays) does not expose Symfony constraint metadata. Bridging to symfony/validator + attributes on DTOs is an architectural change with real cost — likely larger than the documentation benefit.
• The API is REST/OpenAPI. Use dedoc/scramble, knuckleswtf/scribe, or nelmio/api-doc-bundle; this package's output targets JSON-RPC docs, not OpenAPI.
• The API is GraphQL/gRPC, where schema-first tooling already provides the contract.
• Dependency-risk tolerance is low. With no maintainer community, no dependents, and a single maintainer, a security/compatibility audit and a pinned version (or internal fork) is mandatory before production use.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that removes manual effort from API documentation and keeps our published API contract honest. It eliminates a class of integration bugs and support tickets at effectively zero license cost, and the implementation effort is low. The caveat is maturity: it has no meaningful user base, so we treat it as internal code we control — audit it, pin it, fork if needed. Recommendation: adopt as a scoped pilot behind the JSON-RPC surface, not as a platform-wide standard.

To engineering: It converts Symfony Validator constraints into JSON-RPC parameter documentation, so validation rules become the documentation source of truth. Scope is narrow and readable; the risk is maintenance, not complexity. Prerequisites: a real Symfony Validator layer on request DTOs, JSON-RPC as the transport, and CI generation so drift is caught at build time. If we're on Laravel validation arrays or REST/OpenAPI, the integration cost outweighs the benefit — we should decline and use the OpenAPI tooling instead.