This message was deleted.
# general
s
This message was deleted.
w
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:
Copy code
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"
)
f
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
w
cc @creamy-potato-29402 who has been thinking about adding these type-helpers for other reasons - this is another compelling case.
f
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
To deploy it via pulumi, i’d write a
k8s.yaml.ConfigGroup
that points that entire folder
having those casts inside the
if
statements would make it really easy to be able to target modifications to a specific file since I’ve already split them out by type
This a really old thread bump, but I think the optional chaining that will be shipped in typescript 3.7.0 will eliminate some of the boilerplate here: https://github.com/microsoft/TypeScript/issues/16#issuecomment-515160784