Repository navigation
fix: treat JSON property names literally - #131
fitchmultz wants to merge 1 commit into
Conversation
|
Local verification is complete for 81d9359: 1,067 unit tests and 7,513 spec tests pass, plus the native build and CJS/ESM smoke checks. The upstream CI run is currently |
d0e5a0a to
c9ed628
Compare
|
Hi Mitch, currently last of your PRs. 🙏 Would you mind doing a rebase and resolve the current conflicts? |
|
Rebased your branch and opened a new PR for your changes here #144. Thank you so much for contribution! Highly appreciated! |
|
Thanks, Sascha! I really appreciate you taking care of the rebase and getting these fixes released. I checked #144 and ran the nine literal-property/pointer regression cases against the published Thanks again for integrating this and the other PRs! |
|
You are welcome. Thank you again and thanks for checking the release! |
Property names that match
Object.prototypemembers aren't treated as plain names:toStringorconstructorcan crash validation (node.validators is not iterable)additionalProperties: falseanddependentRequired__proto__property can disappear when schemas are mergedNames containing
/or~also produce wrong pointers. For example,{ "a/b": 1 }is reported at#/a/b.Lookups now go through own properties (
getValue/hasProperty). The dictionaries that hold property names are created withObject.create(null). Pointer escaping lives in two helpers:iteratePropertiesgives each schema property its pointer tokenappendDataPointerbuilds data pointersData pointers stay readable. Only
~and/are escaped, plus%in#pointers so thatgetNodereads them back correctly. Errors fromgetNodenow carry data pointers too. The reduce step used to report the schema path (#/properties/choice), and theadditionalProperties: falseresolver reported just the bare key.Tests are in src/tests/issues/own-json-properties.test.ts and src/tests/issues/property-pointer-escaping.test.ts.
AI disclosure: This pull request was prepared with AI assistance and reviewed by me.