Json Laravel Package

Technical Evaluation

Architecture fit: Poor to conditional. hoa/json is a standalone, framework-agnostic PHP JSON library, not a Laravel package. It provides a low-level JSON document/AST-style API rather than Laravel-native integration such as a service provider, facade, config, or queue/event hooks. Laravel already covers common JSON needs with json_encode/json_decode, Symfony Serializer, and supported JSON Schema/JSONPath packages. A TPM should treat hoa/json as an isolated utility only if a legacy system already depends on its specific AST behavior.

Integration feasibility: Low. The package is archived, last released 2017-01-13, has 13 stars and 0 dependents. Modern Laravel applications typically run PHP 8.1+, while this package predates contemporary PHP compatibility and Composer constraint practices. Installation may require legacy transitive Hoa dependencies, platform-requirement overrides, or a fork. There is no Laravel ecosystem support and no active maintainer path for compatibility fixes.

Technical risk: High. Key risks include unmaintained code, no security patch process, PHP 8.x incompatibility, Composer dependency conflicts, possible Hoa stream-wrapper/autoload side effects, and behavioral differences from native JSON handling. Zero dependents and low stars indicate little community validation. The opportunity score of 4.48 should not be read as production readiness; the archived status and release age dominate.

Key questions: What exact capability is needed: JSON parsing, JSON AST manipulation, streaming, or schema validation? Can Laravel-native JSON plus a supported schema validator replace it? What PHP and Laravel versions must be supported? Are there existing transitive Hoa dependencies? Is the license compatible? Would we fork and own maintenance, or replace it? What characterization tests prove behavioral parity? Is there a hard legacy constraint, or is this only a research/reference use case?

Integration Approach

Stack fit: Weak. Do not introduce hoa/json into a greenfield Laravel application. For schema validation, prefer supported packages such as opis/json-schema or justinrainbow/json-schema; for streaming large JSON, evaluate halaxa/json-machine; for JSONPath, use a maintained JSONPath package. If hoa/json must remain, isolate it behind an application-owned adapter interface rather than letting Hoa types leak into controllers, jobs, or domain services.

Migration path: For brownfield usage, inventory every call site, write characterization tests around current behavior, wrap the dependency in an adapter, then replace the adapter implementation with native JSON or a supported library. Sequence: discovery, test harness, adapter isolation, replacement in non-critical paths, production validation, removal of the Composer dependency. If short-term retention is unavoidable, vendor/fork the package, pin the exact version, and add CI coverage.

Compatibility: Expect friction with Laravel 9/10/11 and PHP 8.1–8.3. Validate with composer why-not hoa/json, a PHP matrix in CI, and autoload checks. Do not rely on --ignore-platform-reqs as a production strategy. Confirm whether Hoa stream wrappers or global state are registered, because those can affect unrelated Laravel components.

Sequencing: Treat replacement as technical debt reduction. First prove whether the feature can be delivered with native JSON plus a supported validator. Then build the adapter and parity tests. Finally remove hoa/json before scaling the service. For new work, reject adoption unless a documented legacy constraint makes replacement impossible.

Operational Impact

Maintenance: High burden with no upstream maintenance. The team owns all bug fixes, PHP compatibility updates, security review, and Composer constraint management. A fork requires an owner, release process, and patch policy. Low stars and zero dependents mean little external support or community testing.

Support: No vendor support, no active CVE process, and stale documentation. Internal runbooks should document why the dependency exists, who owns the fork, how to patch it, and the removal plan. Ramp-up is moderate for developers familiar with JSON but higher for Hoa-specific AST APIs and stream-wrapper behavior.

Scaling: No meaningful adoption or performance evidence at scale. Object-heavy AST parsing may consume more memory than native json_decode for large payloads. Load-test representative JSON sizes and concurrency before using it in request paths. Prefer streaming or native decoding for high-volume endpoints.

Failure modes: Composer resolution failures, PHP fatal errors after runtime upgrades, autoload or stream-wrapper conflicts, uncaught Hoa exceptions, silent behavioral differences from native JSON, schema-validation gaps, and unpatched security issues. Add monitoring around parse failures and dependency health, and keep a tested fallback path.

Ramp-up: The library is small enough to learn, but the operational overhead is disproportionate. A TPM should position it as legacy-only, time-box any investigation, and fund replacement rather than normalizing it as a strategic Laravel dependency.