This message was deleted.

This sounds like it might not be a great idea. If you mean a collection of Pulumi resources, it just won't work; you can't marshal a real resource in one stack from the JSON object exported from another stack this way. Even if you could, how would you tell the new stack that this resource is unmanaged (which you would have to, because it is managed in the exporting stack). If you mean a collection of objects, it can certainly work, but in my experience, maintaining an interface that both the exporting and importing stack can use is a bit of a pain. At least in Typescript, the interfaces aren't quite compatible, and it tends to be easier to have two interfaces, one for exporting (with Outputs) and one for importing (with Inputs). And these two interfaces have to be equivalent at all times. It's usually not worth the effort, it's just easier to export the required values. Generally, the rule is to export whatever strings you might need in other stacks. These tend to be the sorts of values that non-Pulumi APIs needs: ARNs, IP addresses, domain names and the like.

To chime in with what @little-cartoon-10569 says - it seems like the approach recommended is not to do what you think you should do - which is to export an actual object from one stack to another - but instead export just the unique identifier - a resource id, IP address, URL, etc. I did the same thing when I was starting out oh-so-long-ago (Thursday).

Sorry my description was misleading. Yes I know publishing a whole Pulumi resource object doesn't really work (you end up with some internal representation dumped as a JSON object which doesn't serve any purpose)

What language is this? In Typescript, all properties are lifted automatically, so you can skip the

apply()

. Does this not happen here?

export resourceId = resource.id

It just works.

It's F#, a .NET language. Lifting for statically typed languages seem to be much more limited than dynamic languages. I have to say the C# example here https://www.pulumi.com/docs/intro/concepts/inputs-outputs/#lifting is so limited that it isn't adding much value, the mechanism isn't implemented for Java yet, and F# isn't even mentioned but the situation is probably pretty much the same with C#.

I'd guess not, then. However it might be possible to use a reduce-type pattern to achieve this to a Map/Dictionary object? A function that takes a Map<string, Output<string>>, an Output and a property name, then just does something like

map[property] = yourOutput.Apply(o -> o.property)

(lots of reflection, no doubt). Assuming that there's an easy way to map Maps to JSON when exporting, that should be okay.