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

The function serialization restrictions that you're referring to apply to things like inline lambda definitions. When you inline a function in a lambda like in this example:

<https://github.com/pulumi/examples/blob/master/aws-ts-s3-lambda-copyzip/index.ts#L12-L25>

A "compiler" runs and produces a js closure that can run on lambda independently, capturing necessary dependencies, etc.

If you're just writing a plain old pulumi program that runs on your laptop, there shouldn't be any function serialization going on.

According to <https://www.pulumi.com/docs/intro/concepts/programming-model/#how-dynamic-providers-work|https://www.pulumi.com/docs/intro/concepts/programming-model/#how-dynamic-providers-work>

&gt; Because your implementation of the resource provider interface must be used by a different process, potentially at a different point in time, dynamic providers are built on top of the same function serialization that is used for turning callbacks into AWS Lambdas or Google Cloud Functions. Because of this serialization, there are some limits on what can be done inside the implementation of the resource provider interface, which you can read more about in the function serialization documentation.

The compiler is invoked in the second phase

I figured it out now. i pulled the require calls of the native node modules inside the update function of the provider instead of having them at the top of the file. and with that change it works like a charm. :tada:
However, i am still not sure how the provisioner example works. :sweat_smile:
but at least i found an acceptable work around.

Ah, I missed the part about it being a dynamic provider. Sorry for the confusion!