feat(input_schema): Add propertyNames and patternProperties for object property

[mfori]

Input schema: propertyNames and patternProperties support

This is the last step required (by https://github.com/apify/apify-core/issues/24338) to deprecate our custom validation keywords patternKey and patternValue in the input schema, because they are not part of the JSON schema spec.

More info about the deprecation is here: https://www.notion.so/apify/Deprecation-of-our-custom-validation-keywords-in-the-input-schema-2a9f39950a22800d9252ed2a6ee7521c?source=copy_link

Currently, for array fields, these are already (very easily) replaceable with the sub-schema. But for object fields these two works differently:

• patternKey validates all object keys against the pattern regex
• patternValue validates all object values against the pattern regex

...And there are validation keywords exactly for this use cases in the JSON schema spec.:

propertyNames

https://json-schema.org/understanding-json-schema/reference/object#propertyNames

{
  "type": "object",
  "propertyNames": {
    "pattern": "^[A-Za-z_][A-Za-z0-9_]*$"
  }
}

This validates all property names (keys) of the object against the pattern regex.

patternProperties

https://json-schema.org/understanding-json-schema/reference/object#patternProperties

{
  "type": "object",
  "patternProperties": {
    "^S_": { "type": "string" },
    "^I_": { "type": "integer" }
  }
}

This allows to validate a schema against all properties that match the pattern regex.

So to replace the patternValue behavior, we would need to define a schema like this:

{
  "type": "object",
  "patternProperties": {
    ".*": {
      "type": "string",
      "pattern": "^[A-Za-z_][A-Za-z0-9_]*$"
    }
  }
}

Pattern .* says that this schema should validate all properties.

⚠️ Important: The current implementation limits the schema of patternProperties exactly to this shape. So there has to be always a single object property named .* with properties type (only string) and pattern (validates whether it's compilable regex). This can be relaxed later if there are use cases for that (define a different pattern to match properties, define a different validation keywords then pattern), but for now this is only for replacement of the patternValue keyword.

[Copilot]

Pull request overview

This PR adds support for propertyNames and patternProperties keywords to the input schema, enabling validation of object property names and values according to JSON Schema specification. These keywords are intended to replace the deprecated custom validation keywords patternKey and patternValue.

Key Changes:

• Added propertyNames support to validate all object keys against a pattern regex
• Added patternProperties support to validate all object values matching a pattern (currently limited to .* pattern with string type)
• Extended validation logic to check regex patterns for the new keywords

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
packages/json_schemas/schemas/input.schema.json	Adds JSON schema definitions for propertyNames and patternProperties, with references added to object field definitions
packages/input_schema/src/types.ts	Adds TypeScript type definitions for the new properties in ObjectFieldDefinition
packages/input_schema/src/input_schema.ts	Implements validation logic for regex patterns in new properties and adds error handling for propertyNames validation errors
packages/input_schema/src/intl.ts	Adds internationalization string for property name validation errors
test/input_schema.test.ts	Adds comprehensive tests for validating the new keywords, including error cases and type restrictions
test/utilities.client.test.ts	Adds integration tests verifying runtime validation behavior for both new keywords

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jancurn]

Looks good from a quick look, but I don't feel qualified to approve this PR

[mfori]

Ping @mtrunkat @fnesveda @gippy @metalwarrior665

[metalwarrior665]

Are there some real-world use-cases for this? I think we only used these for arrays where it is easily fixable already? Considering the complexity of the input schema, if we don't need a feature, we probably shouldn't introduce it.

A middle ground might be to just list the supported JSON schema features, rather than describing them from scratch in the main docs page.

[mfori]

Are there some real-world use-cases for this? I think we only used these for arrays where it is easily fixable already? Considering the complexity of the input schema, if we don't need a feature, we probably shouldn't introduce it.

We have the (patternKey and patternValue) feature for objects currently too, so I guess there is (was) some use case for it. And once we deprecate patternKey and patternValue, we need to provide Actors that use it some alternative.

[metalwarrior665]

We have the (patternKey and patternValue) feature for objects currently too, so I guess there is (was) some use case for it.

But was it used in any existing Actor? Or one that has some public usage?

[mfori]

But was it used in any existing Actor? Or one that has some public usage?

Ok, I checked public Actors in the store, and none of them are using it for objects. So you think that we can just deprecate (and remove later) this feature without offering an alternative? And we can add it later if someone requests it.

I guess there had to be some use case for it, so it was implemented, but probably it's not relevant anymore since it's not used by public Actors.

[mtrunkat]

👍

[metalwarrior665]

So you think that we can just deprecate (and remove later) this feature without offering an alternative? And we can add it later if someone requests it

Yep

[gippy]

I have been thinking about this, and Lukas is probably right. If none of the current public Actors use the validation for keys/values of objects, then we can deprecate it/remove it. We did not have a reason when we added it initially in the first version of the input schema. It was added just because we were also adding the validation for arrays.

[mfori]

Ok, I'm making this draft (to be sure the branch is not deleted by the new job 😄), and we can add this later if requested. Thank you all.