Json Laravel Package

Product Decisions This Supports

• Error-handling policy for JSON boundaries. This package exists to turn json_encode/json_decode's return-false-and-set-json_last_error() contract into thrown exceptions. The PM decision it informs is whether malformed payloads (third-party webhooks, cache entries, config blobs, API responses) should fail loudly at the boundary or degrade silently deeper in the stack. That is a real reliability decision with incident and on-call consequences, not a library preference.
• Build vs. buy for a ~30-line utility. The capability is a thin wrapper. It is a useful forcing function to ask: do we want a dependency, or an internal Json::decode() helper with typed exceptions that we own? Given 3 stars, zero dependents, and a 2019 last release, "buy" has almost no defensive value here.
• Legacy PHP upgrade sequencing. If a service is pinned to PHP 7.1/7.2, this is a stopgap that lets code adopt PHP 7.3's exception semantics before the runtime upgrade lands. That makes it a scheduling input for the platform-upgrade roadmap: adopt-temporarily-and-delete, not adopt-and-keep.
• Consistency across services. If multiple teams hand-roll if (json_last_error() !== JSON_ERROR_NONE) checks with inconsistent messages and exit paths, a shared wrapper (internal) is a legitimate standards decision. The package is only evidence that the pattern is wanted, not that it should be vendored.
• Not a differentiator. Nothing here touches customer-facing capability. Route it through engineering hygiene, not the product roadmap.

When to Consider This Package

Consider it only when all of the following hold:

• The runtime is PHP < 7.3, where JSON_THROW_ON_ERROR and JsonException do not exist. (Note: 7.2 and earlier are long past end-of-life; this is a shrinking set.)
• You need exception-based JSON semantics now and cannot add a ~30-line internal helper this sprint.
• The usage is confined to an internal, low-blast-radius code path, and you accept an unmaintained dependency with no security response plan.

Look elsewhere (or write it yourself) when:

• The runtime is PHP 7.3+. Use native json_encode($v, JSON_THROW_ON_ERROR) / json_decode($s, true, 512, JSON_THROW_ON_ERROR). This package's core value proposition is now the language's default behavior.
• You need structured serialization, schema validation, or typed DTO hydration — use Symfony Serializer, Laravel's validation/casting layer, or a dedicated mapper. This is not that.
• You are making a dependency decision you expect to defend in a year. Three stars, zero dependents, no releases since February 2019, and no downstream usage to surface regressions means you are the maintainer in practice. Vendor risk is high; switching cost if abandoned is trivially low but so is the benefit.
• You already have a JSON boundary convention. Duplicating wrappers fragments error types, which is exactly the problem you set out to fix.

How to Pitch It (Stakeholders)

For executives (one paragraph): A tiny, unmaintained utility that makes PHP's built-in JSON functions throw exceptions instead of silently returning false. The language absorbed this behavior in PHP 7.3, so its window of value has closed. Recommendation: do not adopt as a dependency. If we want exception-based JSON at our boundaries — and we should — we replicate the behavior in roughly a day of internal work we fully control, or we simply rely on the native flag once we are on a supported PHP version. This is a hygiene note, not an investment.

For engineering (the actual ask):

• The pattern is worth standardizing; this implementation is not worth vendoring. Zero dependents and no releases since 2019 means no ecosystem pressure testing.
• Preferred path: a small internal Json helper that wraps json_encode/json_decode, throws a project-owned JsonException with the payload context attached (a field PHP's own exception won't give you), and is the single place we change when we move to JSON_THROW_ON_ERROR.
• Migration note: on PHP 7.3+, delete the helper's guts and delegate to the native flag — the call sites and exception type survive the swap. That keeps the exit cost near zero and makes this a reversible decision.
• Guardrail: never let raw json_decode return values leak past a boundary without a check; that is the failure mode the wrapper exists to prevent.