Generate types and type specs for all generated functions in aws-elixir and aws-erlang

[onno-vos-dev]

Triggering the build and for now this should be considered a DRAFT and a Request For Feedback. The code is a mess and needs some cleaning up and combing over but opening it up in order to get feedback from others.

Generated aws-elixir code as an example: comparison
Generated aws-erlang code as an example: comparison

[philss]

Nice! I gave a first pass and it's looking good.

Please let me know when to review again :)

[aronisstav]

Solicited opinion: the output comparison of an erlang module looks good enough to me.

I think that it will likely be unreasonably hard to code anything that can "prettify" the "flat", "expanded" generated types, and the point should be more "easier doc generation" than the code itself being small... I didn't check, and I am still not using aws-erlang but perhaps one can offer a minified version of the library without types in that case.

Good job! 😄

[onno-vos-dev]

Solicited opinion: the output comparison of an erlang module looks good enough to me.

I think that it will likely be unreasonably hard to code anything that can "prettify" the "flat", "expanded" generated types, and the point should be more "easier doc generation" than the code itself being small... I didn't check, and I am still not using aws-erlang but perhaps one can offer a minified version of the library without types in that case.

Good job! 😄

I tried to generate the edocs (using rebar3 ex_doc) for the generated types but apparently edoc explodes trying to parse the binaries <<"BinaryThingy">> as if it's an XML-tag so I gotta figure out how to deal with that 👍 But then yes, the idea would be to have good docs on the types and hence aid developers in having more information on what's expected as input into the APIs 👍

Thank you for the comment 🙇‍♂️

[onno-vos-dev]

Updated generated code examples that are in the description.

Main changes pushed are:

• Generate common errors in order to unify types and reduce noise
  • Thanks Jesper (colleague) for that tip ❤️
• Ensure that for Elixir, typedoc examples are considered code blocks
  • Thanks @LostKobrakai for that tip! ❤️

Reception from colleagues, @LostKobrakai and @philss have been good 👍
I haven't seen anyone yelling "NOOOOO!" on Elixir/Erlang Slack so I'll polish this up over the coming days so we can get this into a mergeable shape 👍 I'm quite happy with how the output looks, just need to polish up some of the cr*ppy code I wrote in this branch 😄

[onno-vos-dev]

• Get rid of code duplication in .eex modules
• Move some of this parameter types stuff that currently lives in rest_service.ex to types.ex or a similar module
• Fix rest_service:join_parameter_types to not have as much nesting
• Shapes could probably be moved to one module and hence reduce the clauses in types.ex
• collect_shapes/2 is the same across both post and rest similar with is_input/1
• Are the things living in Util really living in the right place?

[onno-vos-dev]

Declined in favor of #109 due to wrong branch naming.