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.

Pulumi Community

As of <https://github.com/pulumi/pulumi/pull/1655>, the story here should be vastly improved. The only "gotchas" we are aware of are

1) `@pulumi/*` modules are not serialized by default, because they are deploy-time-only (and can be quite large)
2) mutable modules that get serialized will be deserialized using a `require`, meaning mutations could get lost

So, hopefully, the 99% case just works fine. <@UB9JVTW07> <@UB3BGTV63> Any plan on when we'll cut a new SDK build with these fixes?

I expect we'll cut a new release later this week.  But you can always pick up the latest from master by using `"@pulumi/pulumi": "dev"` in package.json if you want to try new things out early.

Indeed.   Let us know if you rnu into any issues.

And, hopefully, those 'gotchas' Joe mentioned are things that you shouldn't really ever be running into.

So this example is still giving problems:

<https://gist.github.com/jen20/57000fdbc95455fbeeb5e181b1ddbaf1>

It half looks like it is an issue with one of the downstream libraries, though it works ok with a `require()` in the function body

I *think* the reason this isn’t working is that the transitive dependencies on “@pulumi/pulumi” from the dev builds of “@pulumi/aws” are not themselves picking up dev builds. I suspect you package-lock.json will show non-dev copies of Pulumi/pulumi.  We’ll need to fix this to make sure it’s possible to test with latest dev builds across the stack of package dependencies.   We’ll also aim to do another release of these packages soon. 

<@UB9JVTW07> just to make sure - are you able to verify that this example does work correctly with the latest changes in master?

Ah I can try installing from source instead and using that

Actually, is there a good way to do that right now? Installing from source and then using `yarn link` doesn’t appear to affect transitive dependencies

Yeah - unfortunately this is not simple to do right now.  <@UB9JVTW07> and <@U87DZN4MT> are working on making it easier to link across layers in the stack.

That case may not actually work.  I will have to test later.  This is because of how capturing likely works with "new slack.WebClient".

<@UB3BGTV63> this isn't working because our module resolution logic shows that module's name as being:

`./node_modules/@slack/client/dist/index.js`

which ends up looking like a "local module" to us

a simple fix would be to just actually see if it's accessing into ./node_modules and treat that as "should capture by reference"

however, it's unclear to me if that's just a hack that's fixing an issue, and if we should fix this at a deeper level.