Json Laravel Package

Technical Evaluation

Architecture fit. Despite the "Laravel/PHP package" framing, this is not a Laravel package in any framework sense — no service provider, facade, config, migrations, or published assets are implied by its description. It is a single-purpose utility wrapper whose entire value proposition is replacing json_last_error() checks with an exception surface. That problem was absorbed into the PHP language in 7.3 via JSON_THROW_ON_ERROR, and the package's last release (2018-06-14) predates that. For a Laravel app on PHP 8.x there is no architectural slot for it; for a Laravel app on PHP 7.3+ there is no functional gap to fill. The only plausible fit is a legacy PHP 5.6–7.2 service where json_last_error() boilerplate is pervasive and the team wants a uniform exception contract.

Integration feasibility. Mechanically high: composer require, autoload, find-and-replace call sites. Strategically low: archived repository, no release in seven years, 93 stars and zero dependents — essentially no ecosystem validation and no downstream canary. Composer will likely surface it as abandoned, and supply-chain scanners will flag it. Installation may also be blocked or untested on modern PHP depending on the declared platform constraint.

Technical risk. Low runtime surface (a thin wrapper), but unmaintained code against evolving PHP runtimes carries known-unknowns: implicit nullable parameter deprecations, dynamic property deprecations, and exception-class behavior changes. No upstream security response path exists. The larger risk is organizational: adopting it normalizes adding a micro-dependency for a language primitive, which compounds review and audit tax across teams.

Key questions.

• What is the PHP floor across the services that would consume this?
• Is there any legacy PHP < 7.3 estate that genuinely lacks JSON_THROW_ON_ERROR?
• Does any existing code depend on the specific exception class or message text rather than just "throws on error"?
• Do we already have an internal JSON utility or coding standard for decode/encode error handling?
• What does our abandoned-dependency / SBOM policy require for archived packages?

Integration Approach

Stack fit. Framework-agnostic, so it "fits" Laravel by not touching Laravel. But Laravel already covers the surrounding concerns natively — the json validation rule, Illuminate\Support\Js, JsonResponse, and json_decode(..., JSON_THROW_ON_ERROR) — while this package covers only the decode/encode primitive. Net new capability: zero.

Migration path. Treat it as a replaceable leaf dependency, not an integration.

1. Inventory call sites by namespace (grep across the monorepo and any consuming services).
2. Introduce an internal Json::decode() / Json::encode() helper with the desired signature and exception contract.
3. Implement the helper as a one-liner over json_decode(..., JSON_THROW_ON_ERROR) where PHP ≥ 7.3; fall back to the package's source only in the rare < 7.3 case.
4. Swap call sites to the helper, then remove the public dependency.

Compatibility. Verify the package's composer.json PHP constraint against the target platform before promising anything. Test behavioral parity explicitly: exception type and message, depth default (512), associative-vs-object default, JSON_BIGINT_AS_STRING handling, and partial/empty input behavior. Native JsonException is not the same class as the package's exception, so any catch blocks keyed to the package type are migration work.

Sequencing. (1) Confirm PHP floor per service. (2) If any service is < 7.3, define the internal helper and vendor the logic. (3) If all services are ≥ 7.3, skip adoption entirely and use native calls. (4) Record the decision in an ADR. (5) Add a CI/lint rule discouraging json_last_error() in new code so the problem does not recur.

Operational Impact

Maintenance. Near-zero code maintenance but non-zero process overhead: dependency review, SBOM entries, CVE-scanner noise for an archived package, and a "who owns this if it breaks" question with no good answer. Archived means no upstream fixes — any bug becomes ours, which is the same as owning a three-line helper without the licensing ambiguity.

Support. No vendor, no SLA, no maintainer. GitHub issues on an archived repo are read-only. Internal support burden is trivial precisely because the code is trivial — which is also the strongest argument for not carrying it.

Scaling. Not a throughput concern; cost is one function call. The scaling concern is organizational: every added micro-dependency is a review, audit, and upgrade tax multiplied across teams and years.

Failure modes.

• Exception-type mismatch after a refactor or a fork patch.
• Silent divergence when native json_decode and the wrapper coexist in one codebase.
• Composer resolution conflicts if the declared PHP constraint is narrow.
• Policy violation in regulated environments that prohibit abandoned dependencies.
• False confidence: teams assuming "there's a package for this" means the concern is handled end-to-end, when it only covers encode/decode errors.

Ramp-up. An engineer reads the source in minutes; learning curve is effectively zero. The real ramp-up cost is the decision record, the code review of the migration, and the eventual removal if adopted — roughly 0.5 engineer-days to adopt, ~1 engineer-day to remove cleanly. Low effort, but negative expected value.

TPM recommendation. Do not adopt. Leverage the package's premise — exception-based JSON handling — via PHP's native JSON_THROW_ON_ERROR behind a thin internal helper, or vendor the ~50 lines into the internal utility library under MIT attribution if a pre-7.3 service truly requires it. Log it as a one-line ADR, close it, and spend the opportunity budget on packages with active maintenance and real dependents; the 0 dependents, archived status, and 18.14 opportunity score all point to deprioritization rather than integration.