-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider generating encoders for output args #423
Comments
Don't we generate that already? There are two options if we don't: b) provide an inline given for Encoders in exports that reach user's code and therefore allow user to derive Encoder on demand Option A has the benefit of us knowing on package publishing level that something is no yes with caveat of swollen packages. Option B has the benefit of smaller package size with caveat of missing given errors exposed to the user if something can't be derived. There's a middle ground option of verifying that we can derive all Encoders for all output args in some kind of post-build test stage (would require two stage generation in codegen, one package would be the core package that we publish, second would depend on first and just verify that we can derive Encoders for all output args so compile failure would prevent publish of first package). |
We have encoders for input args but not for output args, only decoder there. This works OOTB in other implementations, so my expectation, if I was a use, was to be of parity. I agree this adds code to providers and technical limitations of that needs to be taken into account. |
The following use case:
Requires the following workaround:
To get this output from
pulumi
:The text was updated successfully, but these errors were encountered: