Json Laravel Package

Product Decisions This Supports

• API contract enforcement (schema-first vs. hand-rolled validation). The package's core value is JSON Schema validation on top of linting. If your roadmap includes publishing or consuming a JSON Schema contract (open API, partner integration, webhook payloads), this tells you whether a thin schema-validation layer is enough or whether you need a full contract-testing toolchain.
• Where to enforce input validation. A PM decision about where bad JSON is caught: at the edge (middleware / request rule), at the service boundary, or in CI. This package is best framed as a CI/CLI and batch-validation tool, not a per-request middleware dependency.
• Build vs. buy for a ~200-line utility. Linting JSON and validating against a schema is small, well-understood work. The real decision is "add a dependency" vs. "write the 40 lines ourselves" vs. "depend on the one maintained library underneath." That comparison is the deliverable.
• CI/dev-experience investment. The bundled jsonlint CLI supports a pre-commit hook or pipeline stage that validates composer.json, config manifests, and fixture files before merge — a cheap reliability win to scope into a platform/DX epic.
• Third-party and configuration ingestion. Use cases where humans hand-edit JSON (feature flags, tenancy config, import files) are where linting plus schema validation pays for itself in reduced support tickets.
• Dependency risk register. Stars (60), a NOASSERTION license, and an unmaintained release cadence are themselves a product decision input: this belongs on the "do not adopt without a fork/exit plan" list, not the "approved vendor" list.

When to Consider This Package

Consider it when:

• You are on a legacy PHP 5.6/7.x Laravel codebase where the package's constraints still resolve, and you need JSON Schema validation plus a CLI linter without introducing several new dependencies.
• Your need is tooling-adjacent — a CI lint step, a fixture validator, an internal admin utility — rather than a runtime request path.
• You want a reference implementation to copy. The Json facade-style wrapper (decode, encode, lint, validate) is a reasonable API shape to imitate in a first-party helper.

Look elsewhere when:

• You are on PHP 8.1+ / Laravel 10+, which is the default assumption for new work. Laravel already ships a json validation rule and Json rule, so basic linting is a solved problem in core; do not add a dependency for it.
• You need modern JSON Schema drafts (2019-09, 2020-12), $ref resolution across files, or performance on large payloads — evaluate opis/json-schema or justinrainbow/json-schema directly.
• Legal has not cleared the NOASSERTION license. Treat this as a hard gate, not a footnote. Either get written clarification or budget for a clean-room reimplementation.
• You need active maintenance, security advisories, or a supported upgrade path. An unmaintained package in a request path is a supply-chain liability.
• You need JSONC, YAML, or TOML — this is JSON-only.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose library that validates JSON documents and checks them against a schema, plus a command-line linter we can drop into CI. It is not a platform bet. The recommendation is not to adopt it as a dependency — it is unmaintained, and its license metadata is unresolved, which makes it a legal and security liability for a marginal capability. Instead, we take two things from it: (1) a CI lint stage for checked-in JSON, which is low-cost and reduces config-breakage incidents, and (2) a validated pattern for schema-checking partner and webhook payloads, implemented on a maintained library. Net effect: same reliability outcome, no orphaned dependency.

To engineering: Laravel core already covers JSON syntax validation. The only gap is JSON Schema validation, and this package is a wrapper over a dependency you would install anyway. If we need schema validation, depend on the maintained library directly; if we need a linter in CI, thirty lines of first-party code and no new vendor. Revisit only if we inherit a legacy PHP 7 service where it already resolves cleanly — and even then, plan the exit.