This message was deleted.

There is actually no way to do this. The latter implies that the length of the array is known promptly, whereas the former in general the length of the array is only known some time in the future. So there is no way to turn the former into the latter (it contains strictly less information). The example you have below returns a

q: Output<Output<string>[]>

which is probably not what you want. If you can share the context of how you are trying to use this - there is frequently an alternative way to structure things that can avoid the need to know the length of the array promptly.

Yeah the example I provided returned the type you mentioned but it works, I assume pulumi just flattens it in the end. That being said, it works even without me doing anything with it. What I am doing is using zone.nameservers as an argument to records on

aws.route53.Record

It expects

Output<string>[]

while I have

Output<string[]>

Can I assume in the future that they will work interchangeably or is this just a fluke?

The

records

input is of type

Input<Input<string>[]>

which accepts an

Output<string[]>

. https://github.com/pulumi/pulumi-aws/blob/master/sdk/nodejs/route53/record.ts#L381

Yeah but they are different types. Not referring to input/output because I am sure Pulumi tackles that. I am referring to the fact that one is an Array of Strings the other is an Array of Promises.

An input is a T or a Promise<T> or an Output<T>.

Right, but there is a distinction here, I am not sure if I am explaining it properly. You got something that expects

Array<Promise<String>>

But I hand it an

Promise<Array<String>

They are different, but I am sure you tackle it somehow, but from a type safety point of view, I don’t think it’s sound.

The key thing is the outer Input (and that there are two of them). There is no sense in which it expects a

Array<Promise<string>>

. (Technically that is one valid thing it accepts, but it accepts many others including

Promise<Array<string>>

. If you expand out both Inputs into each of the three options in the Union you get a total of 9 options, one of them is exactly the thing you have.

Alright, thanks for taking your time explaining it, appreciate it.

You should be able to pass an Input into a Kubernetes resource in Pulumi. Can you share an example of what you are trying?

So any Pulumi promise type (Input/Output) will be flatten to its T when applied to any kubernetes manifest spec?