Background
qjson's current real-world test data is limited to:
twitter.json (simdjson corpus) — unicode-heavy social media
small_api.json / medium_resp.json — synthetic chat completion payloads
amazon_cellphones.ndjson — product data
Production JSON parsers encounter diverse API response shapes. V8 and simdjson maintain broader corpora to catch compatibility edge cases.
Goal
Expand fixture coverage to include common production API response patterns, improving confidence in real-world compatibility.
Proposed Additions
| Source |
Payload Type |
Why It Matters |
| GitHub API |
Issue/PR responses |
Deeply nested, many optional fields, markdown in strings |
| Stripe API |
Payment objects |
Decimal-sensitive numbers, nested metadata |
| Kubernetes |
Resource manifests |
Deep nesting, large arrays, YAML-originated quirks |
| AWS API |
EC2/S3 responses |
XML-to-JSON conversion artifacts, verbose structures |
| OpenAPI/Swagger |
Schema definitions |
$ref heavy, recursive structures |
Acceptance Criteria
Technical Notes
- Prefer fixtures with permissive licenses (MIT, Apache, public domain)
- Sanitize any PII from real API responses before committing
- Consider adding a
ci: ["pr"] entry for smaller fixtures to catch regressions early
References
Background
qjson's current real-world test data is limited to:
twitter.json(simdjson corpus) — unicode-heavy social mediasmall_api.json/medium_resp.json— synthetic chat completion payloadsamazon_cellphones.ndjson— product dataProduction JSON parsers encounter diverse API response shapes. V8 and simdjson maintain broader corpora to catch compatibility edge cases.
Goal
Expand fixture coverage to include common production API response patterns, improving confidence in real-world compatibility.
Proposed Additions
$refheavy, recursive structuresAcceptance Criteria
tests/fixtures/manifest.jsonwith appropriate checkstests/fixtures/README.mdTechnical Notes
ci: ["pr"]entry for smaller fixtures to catch regressions earlyReferences
tests/fixtures/manifest.json