Heya! Pulumi function serialization is a beautiful feature and the code behind it is so clever. However, it's pretty tightly coupled with the rest of the Pulumi ecosystem and I think the OSS community would benefit greatly from a generic nodejs function serialization package. Has the Pulumi team ever considered generalizing the function serialization component into its own npm package? If not, would the team be open to having someone from the community work on that?

there's no need for that, I find it far better to compile the code outside the pulumi - it makes it compatible with more languages. If you are interested in JS/TS check this thread https://pulumi-community.slack.com/archives/CJ909TL6P/p1709843946316709?thread_ts=1709830442.054359&cid=CJ909TL6P

Thanks for the response Jan. Ben is using esbuild to bundle all the required source code, which it detects based on _imports. T_his neglects a lot of the complexity pulumi is already doing in its closure creation code here, which attempts to serialize only what is necessary for the function to run--plus it grabs variable values at the time of serialization. From what I can tell, Pulumi's existing approach to function serialization is unique and has many benefits over esbuild bundling.

There are several packages broken by the pulumi serialization. Eg. Zod. Also I haven't tested it for lambda at edge which we compile with ncc. Into a single file

Interesting, you're using pulumi serialization for traditional lambdas and ncc bundling (similar to esbuild bundling you were describing above) for lambda@edge? Is the general direction to deprecate pulumi serialization or fix it so zod doesn't break?

We had a lot of problems caused by serialization and abandoned it for good. I have written 1000+ lambdas and always created an artefact before deploymen. Even before pulumi. With all inventions like SAM or serverless framework it worked the most reliable way. As a benefit you do not need to make a lot of changes to deployment api if you swap technology eg. Python, rust, TypeScript, containers. The flow stays the same.

Cool thanks for your input Jan. For me, the biggest benefit of serialization is that you can lock in variable values at a specific point in the program's execution. With the artifact approach, all variables are initialized from their starting values. My hunch is that figuring out true function serialization will unlock new use cases in the js ecosystem, especially for persistent processes like APIs

I saw that someone extracted the function serializatin code and moved it to a standalone package here https://github.com/functionless/nodejs-closure-serializer , although that looks like it was last touched 2 years ago. For our usage within Pulumi, we want it to be integrated with our "Resource" and "Output" concepts, so it's not straightforward to split it out.