-
Notifications
You must be signed in to change notification settings - Fork 211
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
Allow for deciding trait location in SmithyIdlSerializer
#2120
Comments
Can you say more about the use case? |
Sure : there is a use case in our organisation for automating the update of some smithy files depending on some information stored in a database somewhere. The smithy files can also be manually edited to add some additional information, but also read by third parties that seek to manually implement the contracts represented by the smithy models when code-generators are unavailable. In the particular case of structure shapes, a large amount of traits applied on the shape's members negatively impacts the readability of the smithy files, and the |
Thanks for sharing the use case. One thing to keep in mind with trying to automate updates to existing models is that the IDL serializer loses things like comments and any existing formatting. If that’s acceptable, then we can look into extending the serializer to address your use case. Otherwise, when trying to modify models in place and not lose comments or existing formatting, smithy-syntax should be used. |
Yup, we're aware of the loss of formatting and comments when using the serializer, that is absolutely acceptable. The API of the serializer is very convenient, we like it very much. The lack of control over the placement of the traits is the only pain point we're experiencing around it. |
When writing smithy specifications by hand, traits can be written by :
apply
keyword, potentially in another fileWhen rendering a smithy model via the
SmithyIdlSerializer
, it'd be nice to have an option to control whether the trait should be inlined with the shape, or rendered using anapply
statement, in which case it'd be nice to have control over the file in which the apply statement is rendered.The text was updated successfully, but these errors were encountered: