This is more or less the approach Apple's "pkl" takes.

You define your data in the "pkl language", then it outputs it as yaml, json, xml, apple property list, or other formats.

You feed in something like:

    apiVersion = "apps/v1"
    kind = "Deployment"
    metadata {
     name = "my-deployment"
     labels {
      ["app.kubernetes.io/name"] = "my-deployment"
      ["app.kubernetes.io/instance"] = "prod"
     }
    }
    spec {
     replicas = 3
     template {
      containers {
       new {
        name = "nginx"
       }
       new {
        name = "backend"
       }
      }
     }
    }

And then you `pkl eval myfile.pkl -f yaml` and get back:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: my-deployment
      labels:
        app.kubernetes.io/name: my-deployment
        app.kubernetes.io/instance: prod
    spec:
      replicas: 3
      template:
        containers:
        - name: nginx
        - name: backend

The language supports templating (structurally, not textually), reuse/inheritance, typed properties with validation, and a bunch of other fun stuff.

They also have built in package management, and have a generated package that provides resources for simplifying/validating most kubernetes objects and generating manifests.

There's even a relatively easy path to converting existing YAML/JSON into pkl. Or the option to read an external YAML file and include it/pull values from it/etc (as data, not as text) within your pkl so you don't need to rebuild everything from the ground up day 1.

Aaaaand there's bindings for a bunch of languages so you can read pkl directly as the config for your app if you want rather than doing a round trip through YAML.

Aaaaand there's a full LSP available. Or a vscode extension. Or a neovim extension. Or an intellij extension.

The documentation leaves a bit to be desired, and the user base seems to be fairly small so examples are not the easiest to come by... but as far as I've used it so far it's a pretty huge improvement over helm.