Json Laravel Package

Product Decisions This Supports

• Error-handling contract at JSON boundaries. Decide whether malformed payloads from APIs, webhooks, config files, or queue messages should throw and fail fast, or return null and silently degrade. This package exists to force the former.
• Build vs. buy vs. don't-build. The package is roughly 50 lines of glue around two native functions. It's a canonical "this is a build-in-an-afternoon concern, not a dependency" decision, and a useful data point when evaluating any single-purpose utility package.
• Supply-chain / dependency hygiene policy. Archived repo, last release 2018-06-14, zero dependents, 93 stars. A concrete test case for a "no unmaintained packages in require" rule, or for an explicit exception process where the code is vendored and owned internally.
• Language/runtime modernization roadmap. The behavior this package provides has been native since PHP 7.3 (JSON_THROW_ON_ERROR). Adopting it is a signal that a service is pinned to an old runtime — which feeds directly into upgrade prioritization.
• Integration SDK design. If you standardize on a single exception type for serialization failures across internal SDK wrappers, this is a reasonable reference API surface to copy: decode returns a value or throws, never returns null ambiguously.

When to Consider This Package

Consider it only when:

• The codebase is pinned to PHP < 7.3, so JSON_THROW_ON_ERROR isn't available, and you want exception-based JSON handling without sprinkling json_last_error() checks across dozens of call sites.
• You're maintaining a frozen legacy service where rewriting call sites is riskier than adding a small, vendorable helper.
• You need a reference implementation to copy the API shape from — not to depend on.

Look elsewhere (or just don't adopt) when:

• You're on PHP 7.3+. The native flag covers this entirely; the dependency is pure redundancy and adds an unmaintained name to composer.json.
• You're starting greenfield work, or the code is subject to security/compliance review. Archived + no release in seven years + zero dependents means no downstream battle-testing and no one to patch it.
• You need anything beyond the defaults: streaming parse, custom depth limits, big-integer handling, JSON5/JSONC tolerance, or schema validation. Out of scope.
• Your team enforces a maintained-dependencies-only policy. Composer will install it without complaint; you inherit the maintenance burden regardless.

How to Pitch It (Stakeholders)

To executives: This is a tiny convenience wrapper, not a platform bet. It turns json_decode() failures into exceptions so a bad payload fails loudly instead of quietly returning null — a real class of production bug. The catch is that PHP solved this natively in 7.3, in the same year this package last shipped. Recommendation: do not add it as a dependency. If a legacy service genuinely needs the behavior, vendor the ~50 lines and own them. Adoption cost is near zero, but so is the upside, and the maintenance risk is permanently ours. The more valuable output here is a policy: we don't take on archived packages to save a one-line change.

To engineering: The package is archived, unmaintained, and has no dependents — so no one else is exercising it. The entire feature is a flag: json_encode($v, JSON_THROW_ON_ERROR) and json_decode($s, true, 512, JSON_THROW_ON_ERROR). Prefer the native flag; if you need a stable, package-specific exception type, define it in your own codebase and catch JsonException in PHP 8. Treat this repo as a design reference and a substitutability lesson — 93 stars is not evidence of fitness, and a utility package that the language has since absorbed is a dependency you should decline.