Use custom annotations to override type validation during JSON to Typed conversion #369

New Issue

adam · 2025-12-30T01:23:54+01:00

adam commented

2025-12-30 01:23:54 +01:00

Originally created by @avantikasparihar on GitHub (Nov 25, 2025).

Problem Statement
We have a use case where we need to selectively bypass type validation for properties marked with custom annotations during JSON-to-Typed object conversion.

Current Behavior
When using deepToTyped converter to transform JSON data into Pkl Typed objects, all properties undergo strict type validation. For example, if a property is defined as String, the converter will fail if the JSON contains a non-string value.

Desired Behavior
We want to define custom annotations (e.g., @Secret) that, when applied to a property, allow the converter to bypass type validation for that specific property.

Use Case Example
Pkl Schema Definition:

class DatabaseConfig {
  host: String
  port: Int
  
  @Secret
  password: String  // Should accept any JSON value type, not just strings
}

Input JSON:

{
  "host": "localhost",
  "port": 5432,
  "password": {
    "$secret": {
      "type": "",
      "name": "db_password"
    }
  }
}

Please suggest the best approach to achieve this.

What would be the most idiomatic way to handle annotation-based type validation bypassing in Pkl?
Are there existing patterns or mechanisms in Pkl that we should leverage for this use case?

Originally created by @avantikasparihar on GitHub (Nov 25, 2025). **Problem Statement** We have a use case where we need to selectively bypass type validation for properties marked with custom annotations during JSON-to-Typed object conversion. **Current Behavior** When using [deepToTyped converter](https://pkl-lang.org/package-docs/pkg.pkl-lang.org/pkl-pantry/pkl.experimental.deepToTyped/current/deepToTyped/index.html) to transform JSON data into Pkl Typed objects, all properties undergo strict type validation. For example, if a property is defined as String, the converter will fail if the JSON contains a non-string value. **Desired Behavior** We want to define custom annotations (e.g., @Secret) that, when applied to a property, allow the converter to bypass type validation for that specific property. **Use Case Example** Pkl Schema Definition: ``` class DatabaseConfig { host: String port: Int @Secret password: String // Should accept any JSON value type, not just strings } ``` Input JSON: ``` { "host": "localhost", "port": 5432, "password": { "$secret": { "type": "", "name": "db_password" } } } ``` Please suggest the best approach to achieve this. 1. What would be the most idiomatic way to handle annotation-based type validation bypassing in Pkl? 2. Are there existing patterns or mechanisms in Pkl that we should leverage for this use case?

adam referenced this issue

2025-12-30 01:25:08 +01:00

[PR #369] [CLOSED] LSP support #526

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#369