Hi folks, is there any chance someone could take a...
# typescript
d
Hi folks, is there any chance someone could take another look at this issue? I've just tripped over it again, and the previous PR seems abandoned. tl;dr -
pulumi.output
doesn't work on classes, e.g. in
pulumi.output(new URL()).apply(url => ...)
inside the apply,
url
is no longer an instance of
URL
, but just a plain object.
l
You know in JS/TS, classes aren't first-class objects? They're erased at transpile time. Nothing is an instance of a class at runtime. You can use types for this sort of thing, if you want. But not classes.
d
This is TS, yeah. The PR linked to that issue proposed just checking whether the object has a prototype, and if it does, assuming it is a custom class, which seems sensible? Like this:
Copy code
if (Object.getPrototypeOf(x) == Object.prototype) {
  // Is a plain-old-object, recurse into values (existing logic)
} else {
  // Is a custom class, don't recurse (new)
}
l
Not sure. I generally just check for the important properties. There's also a way to check if all the keys of one object are in another, right? It's not a problem I've solved much, sorry.
Maybe for your example,
Object.getPrototypeOf(url) == (new URL()).prototype
would be the right check?
Or URL.prototype? I don't know.
d
Yes, the point of the issue is that this check should happen in the
pulumi.output
function, not my code. I expect to be able to do this:
Copy code
function foo(x: pulumi.Input<URL>) {
  pulumi.output(x).apply(url => /* use url as an instance of URL() here */ )
}
and it currently doesn't work.
Inside the
.apply()
,
url
is a plain old object, not an instance of
URL
. Because
pulumi.output
strips the prototype information. I don't think this is intentional, hence the bug report.
l
Yea, it's awkward. Generics, classes and runtime don't mix in Typescript. I don't think it's a bug though. I think it's a limitation. If the class of the output is defined in your code, how could Pulumi put it back in, within its code?
d
This isn't specific to Typescript, the bug exists in JS as well. If I have an instance of a class (i.e. the object's
prototype
is the class definition), then pulumi shouldn't try to recursively unwrap it, and just treat it as opaque.
Like is done in this proposed PR, it's not clear why it was closed: https://github.com/pulumi/pulumi/pull/13567
l
Ah. Right. If that's what happening, then something can be done about that.
The test in that PR doesn't prove that it will solve your problem though. Might need another test for type checking. Also, what happens if the class contains wrapped properties? Wouldn't we want them unwrapped? 🤔 Maybe not? If
new MyResource().nestedResource
is an
Output<MyComponentResource>
then I guess we wouldn't want it unwrapped. Tough one.