Code generation - what are our options? #2527
Replies: 3 comments 2 replies
-
I think a Roslyn source generator1 would be the best way to build the client. The only one I know of is Footnotes |
Beta Was this translation helpful? Give feedback.
-
I think a good start is to ask what our overall goals are with generation are... Generation... Immediate needs:
Future needs:
Optional considerations/questions:
|
Beta Was this translation helpful? Give feedback.
-
Here's some stats on where we are vs the api spec (pr here) Caveats - this is the number of routes, not the number of endpoints ie "/app" could actually be represented as a GET, PUT, POST, DELETE etc. so there could be many more that aren't represented here. This does beg the question - how close do we have to get before we switch to generated code? Could we generate the models to start with and replace the ones we have at the moment? Number of SDK routes: 328 Matches: 198 |
Beta Was this translation helpful? Give feedback.
-
We’re talking a lot about code gen and I thought it would be good to kick off a chat about it.
So far I’ve successfully generated a postman collection (not really related to this Repo but it was pretty easy). I also unsuccessfully generated a c# client using the ms open api connected service. There is one endpoint with one enum that accepted add, Add, remove, Remove etc. which exploded because you ended up with two enums with the same name, but different values. Doh. So I guess we could ask to change the documentation to only show upper or lower or we find a different tool.
Another thing to consider is extending the generated code with the undocumented endpoints (repos/owner/name is there but repos/id or repository/id aren’t).
Other options could be handlebars or liquid templates to build own own entirely or there must be others out there. I guess we could also consider doctoring the open api json ourselves to make it fit to our need?
Beta Was this translation helpful? Give feedback.
All reactions