Json Rpc Procedure Collect Bundle Laravel Package

Technical Evaluation

Verdict: proceed with a timeboxed spike only. Do not commit to this package on the basis of the 0.0.2 release. The release notes for 0.0.2 contain no changelog, no PR references, and no description — only a diff link against 0.0.1. That means we cannot determine whether 0.0.2 is a safe patch, a silent behavioral change, or a breaking change on a package whose version number permits breaking changes by definition.

Architecture fit. First-order concern: the repository is named json-rpc-procedure-collect-bundle, and the -bundle suffix is the Symfony convention, not Laravel's. The vendor (tourze) publishes Symfony bundles. Before any architecture discussion, confirm whether this ships a Laravel service provider and illuminate/* constraints at all. If it is a Symfony DI bundle, the value proposition — auto-collecting JSON-RPC procedure handlers and registering them via container/attribute scanning — does not transfer directly, because Laravel has no compiler-pass/tagged-service equivalent. The concept is still worth borrowing: an annotation-driven registry that removes boilerplate from RPC method registration is genuinely useful in our stack. The package may not be the vehicle.

Integration feasibility. Unknown and currently unverifiable from the release artifact alone. A 0.0.2 bump tells us the package is alive but not mature. Required inspection before any decision: composer.json requirements, PHP version floor, autoload map, discovery mechanism (attributes vs. interface markers vs. directory scan vs. config list), and whether exposure is opt-in or opt-out.

Technical risk: high. Drivers:

• 0.0.x semver — breaking changes are explicitly allowed at any patch increment.
• No release hygiene — 0.0.2 is undocumented; we cannot diff-and-review what we would be pulling in. This pattern will repeat on every future bump.
• Single-vendor micro-package — typical of a large long-tail of small packages; dependency graph and bus-factor risk.
• Security-relevant surface — a component that automatically discovers and exposes procedures is, by construction, an attack-surface expander. Auto-registration without a hard allowlist is a liability.
• Unproven CI/test posture — nothing in the release indicates a test suite ran.

Key questions.

1. Does composer.json require illuminate/* or symfony/*? Is there a Laravel service provider with package auto-discovery?
2. What actually changed in 0.0.1 → 0.0.2? (Read the commits; the diff link is the only artifact provided.)
3. How are procedures discovered, and is exposure opt-in (explicit attribute) or opt-out (anything matching a pattern)?
4. Supported PHP and Laravel versions? Any conflicting transitive constraints?
5. Is there CI, and what is the test coverage on the collector itself?
6. Does the package leave authn/authz and input validation entirely to the host app, or does it imply a security posture we'd have to unwind?
7. Maintenance cadence — commit frequency, issue responsiveness, and whether 0.0.1 → 0.0.2 was substantive or a metadata bump.

Integration Approach

Stack fit. Resolve the framework question first; everything downstream depends on it. Three outcomes:

• (a) Framework-agnostic core + thin Laravel adapter → viable, adopt with a pinned version.
• (b) Symfony-only → do not integrate as a dependency. Either extract the discovery concept into ~100 lines of our own attribute-scanning registrar, or vendor/fork the collector behind our own interface.
• (c) Unclear/undocumented → treat as (b) until proven otherwise.

Given the naming evidence, plan for (b) and be pleasantly surprised by (a).

Migration path. Greenfield — there is no incumbent collector to migrate from. The important move is containment: define our own ProcedureRegistry contract inside the application and make the package (or our hand-rolled replacement) one adapter behind it. That reduces a future swap at 0.1 or 1.0 to a single class.

Compatibility. Pin the exact version (0.0.2), not ^0.0.2 — the caret range still admits 0.0.3+, which may break. Verify the PHP constraint against our runtime images and confirm no transitive dependency conflicts before touching a production composer.json. Land it in a scratch app first.

Sequencing.

1. Spike, 1–2 days: read the 0.0.1→0.0.2 diff and composer.json; stand up a throwaway JSON-RPC endpoint in a scratch Laravel app; verify discovery behavior and failure modes hands-on.
2. Decision gate: adopt / adapt / abandon. Default bias is adapt unless the spike proves native Laravel support and a hard exposure allowlist.
3. Boundary definition: our own registry interface plus an explicit procedure allowlist config — never rely on implicit discovery in production.
4. CI hardening: pinned version, lockfile diff review gate on every bump, and a test that asserts the registered procedure set matches an expected snapshot (catches both under- and over-registration).

Operational Impact

Maintenance. The dominant cost and the strongest argument against adoption. Pre-1.0 with undocumented releases means every upgrade requires a manual diff review rather than a changelog read. Budget this as a recurring per-release cost, not a one-time integration cost — realistically a few hours per bump, indefinitely.

Support. No commercial backing, no SLA, GitHub issues only, and documentation likely authored primarily for a non-English ecosystem. Assume self-support: if we need a fix, we fork and patch, and we own that patch. That is an acceptable trade for a small utility, unacceptable for anything on a critical path.

Scaling. Low risk if the collector is a build-/boot-time concern (registration at container compile or app boot). Confirm that discovery does not perform filesystem or reflection scans per request. Note that this package almost certainly does not provide the JSON-RPC transport, batching, or HTTP layer — capacity planning belongs to whatever server component we pair with it.

Failure modes.

• Silent under-registration — a procedure fails to be discovered and returns "method not found" only in production, only for the new endpoint. Highest-likelihood failure; mitigated by a registry snapshot test.
• Over-exposure — discovery registers a method nobody intended to publish. Lowest-likelihood, highest-severity; mitigated by an explicit allowlist, never opt-out.
• Build break on a patch bump — container compilation fails after an unrelated composer update. Mitigated by pinning and a lockfile review gate.
• Abandonment — repo goes stale, no support for the next PHP or Laravel major, forcing an emergency rewrite of a component we no longer understand. Mitigated by keeping the adapter thin enough to rewrite in a day.

Ramp-up. Two engineers, low-to-moderate: 2–4 days total including the spike, if the package is Symfony-coupled (DI tags and compiler-pass semantics are learnable but not free for a Laravel-only team). Closer to one day if native Laravel support is confirmed. The ongoing tax is upgrade-review discipline, not initial learning.