Preventing openapi codegen script from emitting duplicate structs/enums

[dgramop]

Closes #154

The exception is placeholder.rs, which appears to intentionally contain duplicate-named structs.

Right now we just store objects by their name. This is for a more immediate fix. Later on, we can have it do a deeper comparison for equality and throw an error if two structs have the same name and different fields.

This seems unlikely considering whatever Stripe is using to generate their openapi docs should prevent this, but it can be a case we handle anyhow.

Supersedes: #161 , #159

[arlyon]

I'm going to have a look at this this week cheers!

[arlyon]

Hi! Thanks for hacking on this. This is a good start, but we need to ensure that the type contents are equal as well, rather than just check the names. Since these are individual declarations in the openapi definition, we have no guarantee that they won't change independently, and we may introduce subtle bugs. I am going to merge the refactoring PR (#160) and have a think how we can support this on top of those changes :)

[dgramop]

Sounds good! I think I'll have to set this up in a way that does a deeper equality check. I'll take a look at the refactored code soon before I start my next approach.

Just curious, why not stick everything in one module? Considering that we re-export everything to the root anyhow, I can imagine this might simplify things and make catching bugs like this easier

[arlyon]

That actually raises a good point that I wanted to get your ideas on; where do the de-duplicated structs live? Do we move them into their own place? Do we generate them in the place that they were first encountered? And given that, how does that affect features? (we may have a struct that only gets included when a feature is included for example). These are all things we need to consider. I think to begin with maybe keeping the deduplicated structs in their own file would be best, and we'll see if we can work out from there.

As to why we don't keep all the api in one file? Part of it is this issue with name clashes, but we also want people to be able to browse the code in a semi-meaningful way and structuring the code nicely helps with overall understanding. Let me know your thoughts! (and thanks for working on this :) )

[dgramop]

That actually raises a good point that I wanted to get your ideas on; where do the de-duplicated structs live? Do we move them into their own place? Do we generate them in the place that they were first encountered? And given that, how does that affect features? (we may have a struct that only gets included when a feature is included for example). These are all things we need to consider. I think to begin with maybe keeping the deduplicated structs in their own file would be best, and we'll see if we can work out from there.

As to why we don't keep all the api in one file? Part of it is this issue with name clashes, but we also want people to be able to browse the code in a semi-meaningful way and structuring the code nicely helps with overall understanding. Let me know your thoughts! (and thanks for working on this :) )

Has this been fixed yet? Totally forgot about this repo lol.

If it hasn't, what if we just stop exporting everything to the root and make all the modules public so folks can directly address the struct they want to use?

[arlyon]

It should be partially fixed by the codegen revamp PR. I am going to close this now but thank you for taking the time anyways to help out despite it not landing. All the best! <3