I don’t know typescript super well, but is there a way to avoid having to do all these null checks when making changes to k8s yaml files via pulumi: https://pulumi.io/quickstart/aws/tutorial-eks.html#running-off-the-shelf-guestbook-yaml ? I still write k8s yaml for most things because we ship that yaml for our users to run (and other tooling is able to injest yaml), but I’d like to be able to “sprinkle” in things like secrets / env vars via pulumi. For instance in that example, there is a section where they’re changing the type of a service to a Loadbalancer:

// Make the 'frontend' Service public by setting it to be of type
                // LoadBalancer
                if (obj.kind == "Service" && obj.metadata.name == "frontend") {
                    if (obj.spec) {
                        obj.spec.type = "LoadBalancer"
                    }
                }

Is there a way to just tell the compiler that

obj

is a k8s

Service

, and just assign obj.spec.type=Loadbalancer directly without needing to check to see if

spec

is a field on

obj

at all?

I can't think of a much better way to write that. We've considered adding type-test methods to all the generated types so that you could do:

if (Service.isInstance(obj)) {
...
}

and get strong typing of

obj

inside the

if

- which is a nice thing TypeScript supports. But that wouldn't help a ton in this particular case. You'd still need to check whether

metadata.name

was

"frontend"

separately. And then you'd still have the possibility that

obj.spec

was undefined, so you'd need to guard against that (unless you were willing to trust that anything with the

name

you are expecting has a non-undefined

obj.spec

? In that case, you could leave off the other

if

and just use

obj.spec!.type = "LoadBalancer"

)

Hmm, alright. Being able to cast inside the the

if

statement would be a huge help to me. Not having ide-support when writing transformations really is like flying blind

cc @creamy-potato-29402 who has been thinking about adding these type-helpers for other reasons - this is another compelling case.

For some more background, I tend to split up the individual resources for a single component into separate files: e.g https://github.com/sourcegraph/deploy-sourcegraph/tree/master/base/frontend