https://pulumi.com
Join Slack
Hi folks, is there any chance someone could take another look at <this issue>? I've just tripped ove...
# 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.
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by