Is there a way to allow non existing properties

[khanakia]

Is there a way to allow non existing properties instead of throwing an error.

Ideally it should only throw error when a require property is missing not when there is an extra property.

This is how usually .env and env file validators also works

it's so annoying currently

configmgr/gen/appconfig/environment/Environment.pkl.go has changed
building...
running...
panic: –– Pkl Error ––
	Cannot find property `enable` in object of type `AppConfig#Otel`.
	
	80 | enable = true
	     ^^^^^^
	at app#otel (file:///test/config/pkl/default/app.pkl)
	
	Did you mean any of the following?
	enableLogs
	enableHttp
	enableTraces
	enableStdout
	enableMetrics
	

goroutine 1 [running]:
configmgr.GetAppConfig()

[bioball]

This isn't possible for regular classes, and isn't a great idea for a variety of reasons; for one, your configuration can possibly be breaking if you add extra properties that the downstream target doesn't know about.

If you want to model arbitrary key-value pairs like env vars, Mapping is the way to go.

E.g.

environment: Mapping<String, String>

In this approach, if you want to require that some names are set, you can use type constraints for that. This example requires that foo and bar exist as entries.

environment: Mapping<String, String>(
  keys.contains("foo"),
  keys.contains("bar")
)

Another pattern here is to use a regular class to describe known names, and a mapping for any extra keys. This is nice because you get code completion, doc comments on both the Pkl and the Go side.

class Environment {
  /// The foo value is something something
  foo: String

  /// The bar value is something something
  bar: String

  /// Any extra values that should be provided
  extraProperties: Mapping<String, String>
}

environment: Environment

[khanakia]

Yes, I can map but that's not what i needed

We do heavily use Pkl and have to do lots of manual testing with different configuration by enabling and disabling.

It's so tiring currently everytime i have comment out, re-generate the config and remove it from app.pkl file too

Anyway thanks 👍

[HT154]

This looks like it might be a good application of local properties. You can create and use local properties anywhere, eg.

otel {
  local enable = true // not part of the class's schema

  enableLogs = enable
  enableHttp = enable
  enableTraces = enable
  enableStdout = enable
  enableMetrics = enable
}

Alternatively, in a situation where you want a default you might consider adding a hidden field. These are part of the schema but are not rendered in output or populated via code generated client libraries.