Skip to content

fix: treat JSON property names literally - #131

Closed
fitchmultz wants to merge 1 commit into
sagold:mainfrom
fitchmultz:fix/own-json-properties
Closed

fitchmultz wants to merge 1 commit into
sagold:mainfrom
fitchmultz:fix/own-json-properties

Conversation

@fitchmultz

@fitchmultz fitchmultz commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

Property names that match Object.prototype members aren't treated as plain names:

  • data keys like toString or constructor can crash validation (node.validators is not iterable)
  • the same keys can get past additionalProperties: false and dependentRequired
  • a declared __proto__ property can disappear when schemas are merged

Names 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 with Object.create(null). Pointer escaping lives in two helpers:

  • iterateProperties gives each schema property its pointer token
  • appendDataPointer builds data pointers

Data pointers stay readable. Only ~ and / are escaped, plus % in # pointers so that getNode reads them back correctly. Errors from getNode now carry data pointers too. The reduce step used to report the schema path (#/properties/choice), and the additionalProperties: false resolver 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.

@fitchmultz

Copy link
Copy Markdown
Contributor Author

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 action_required with no jobs started; a maintainer needs to approve the fork workflow run.

Comment thread src/keywords/patternProperties.ts Outdated
@fitchmultz fitchmultz changed the title fix: validate literal JSON property names consistently fix: treat JSON property names literally Oct 14, 2026
@fitchmultz
fitchmultz force-pushed the fix/own-json-properties branch from d0e5a0a to c9ed628 Compare October 14, 2026 02:57
@sagold

sagold commented Oct 18, 2026

Copy link
Copy Markdown
Owner

Hi Mitch, currently last of your PRs. 🙏 Would you mind doing a rebase and resolve the current conflicts?

@sagold sagold mentioned this pull request Oct 23, 2026
@sagold

sagold commented Oct 23, 2026

Copy link
Copy Markdown
Owner

Rebased your branch and opened a new PR for your changes here #144. Thank you so much for contribution! Highly appreciated!

@sagold sagold closed this Oct 23, 2026
@fitchmultz

Copy link
Copy Markdown
Contributor Author

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 json-schema-library@11.6.16 npm package. All nine pass with both the CommonJS and ESM entry points.

Thanks again for integrating this and the other PRs!

@sagold

sagold commented Oct 23, 2026

Copy link
Copy Markdown
Owner

You are welcome. Thank you again and thanks for checking the release!
Great job!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants