- Is seld/jsonlint a Laravel package, or do I need a service provider?
- seld/jsonlint is a framework-agnostic PSR-4 utility library, not a Laravel package. It ships with no service provider, facade, or config file, so there is nothing to register. You can use it directly anywhere in a Laravel app, including controllers, queued jobs, Artisan commands, and CI scripts. A thin first-party wrapper or singleton binding is optional if you want one place to enforce usage rules.
- How do I install seld/jsonlint in a Laravel application?
- Install it with Composer using composer require seld/jsonlint. It has no transitive dependencies, no runtime services, and no required PHP extensions, and it is MIT licensed. Because there is no Laravel auto-discovery provider, installation is just the Composer dependency. You can then import Seld\JsonLint\JsonParser wherever you need it.
- How do I get better JSON error messages in Laravel?
- Use JsonParser::lint() and call getMessage() on the returned ParsingException to get a line-pointed message with a caret showing the failure position. The intended pattern is to decode natively first and only re-parse with jsonlint when json_decode() fails, so you pay the extra cost only on invalid input. Treat any surfaced message as untrusted output: sanitize it, cap its length, and avoid echoing raw payload fragments.
- Should I use seld/jsonlint instead of json_decode?
- No. seld/jsonlint is designed as a diagnostic companion to json_decode(), not a replacement. It returns the same kind of result but is materially slower, so putting JsonParser::parse() on a hot request path is a performance risk. Decode natively, and fall back to jsonlint only when the native call fails and you need a human-readable error.
- How do I detect duplicate keys in JSON with seld/jsonlint?
- Pass JsonParser::DETECT_KEY_CONFLICTS to lint() or parse() to throw a DuplicateKeyException when duplicate keys are present. Use ALLOW_DUPLICATE_KEYS to collect duplicates as foo and foo.2, or ALLOW_DUPLICATE_KEYS_TO_ARRAY to put all values for a duplicated key into a __duplicates__ array. Whether duplicates are rejected or collected is a product policy decision, not just an implementation detail.
- Can seld/jsonlint parse JSON with comments?
- Yes. The JsonParser::ALLOW_COMMENTS flag parses JSON while allowing and ignoring inline // and multiline /* */ comments. This is a documented deviation from strict JSON, so decide deliberately whether any config surface should accept it and assign an owner for that policy. Without the flag, comments are treated as parse errors.
- How do I validate UTF-8 encoding with seld/jsonlint?
- Pass JsonParser::VALIDATE_UTF8_ENCODING to validate that the whole input is well-formed UTF-8 per RFC 3629 before parsing. On failure it throws an InvalidEncodingException that points at the first invalid byte. The same validation is available standalone through the Seld\JsonLint\Utf8Validator class, so you can reuse it outside JSON parsing.
- Which PHP and Laravel versions does seld/jsonlint support?
- The README mentions PHP 5.3+, but that is documentation lag rather than an accurate support claim. Check the actual composer.json constraint and verify it against your Laravel and PHP version matrix before committing to a support window. The library is framework-agnostic, so Laravel compatibility mainly depends on the PHP version your app runs.
- How do I test JSON validation code that uses seld/jsonlint?
- Because the library is pure PHP with no runtime services, you can instantiate JsonParser directly in unit tests without booting Laravel. Test valid input, invalid input, and each flag you rely on, and assert against getMessage() and getDetails() for exceptions such as ParsingException, DuplicateKeyException, and InvalidEncodingException. If you wrap the library in a first-party adapter, test the adapter's policy behavior rather than the library internals.
- Is seld/jsonlint production-ready and actively maintained?
- Yes. It is a long-lived project with a strong track record, and Composer itself uses it, which is a strong production reference even though metadata can misleadingly show zero dependents. The maintenance profile is one primary author, so churn is low but response times to parser edge cases may be slow. The main production risk is performance misuse on hot paths, which is best handled with code-review and lint rules rather than runtime guards.