Contributing

Contributions should add a distinct behavior that helps test a JSON parser, validator, editor, API, syntax highlighter, or diagnostic tool. Duplicate and low-value variations may be declined to keep the corpus focused.

Choose a location

• Put syntax that strict parsers should accept in valid/<subcategory>/.
• Put syntax that strict parsers should reject in invalid/<subcategory>/.
• Put valid syntax with representation limits, interoperability concerns, or parser-specific behavior in edge-cases/<subcategory>/.

Create a focused subcategory only when no existing directory fits. Add or update its README.md when the category needs explanation.

Naming and contents

Use lowercase kebab-case filenames ending in .json, such as leading-zero.json. Names should describe the behavior, not an issue number or parser. Keep test cases minimal enough that a failure is easy to diagnose. Invalid test cases are test data: do not correct or automatically format them.

Use UTF-8 and LF line endings. Avoid a byte-order mark unless the BOM itself is the behavior under test.

Update the manifest

Add exactly one entry to test-cases.json, preserving path order. IDs are stable, unique, lowercase kebab-case identifiers. Use:

• accept for strict, portable JSON syntax;
• reject for syntax outside RFC 8259 and ECMA-404;
• implementation-dependent for valid syntax whose representation or downstream behavior can differ.

Describe observed parser-specific behavior in notes without presenting one implementation's result as a syntax rule. Cite the parser and version when relevant.

Test and submit

Run:

npm test

The validator checks parsing expectations, unique IDs and paths, missing files, and unindexed test cases. In your pull request, explain what new behavior the test case covers and complete the checklist. Keep the change limited to the test case, its manifest entry, and directly relevant documentation.